Visual Basic is object-oriented programming?

[JimmyK]

Hi,
Microsoft books say that VB is event-programming. Why dont they say VB is object-oriented programming?

And it is said that VB is less object-oriented than Visual Foxpro!

What do you think ?
Jimmy Le
nhan_tiags@yahoo.com

 

[jfrost10]

I work for a company that's main product is VB based, and its entirely done with object oriented principles. So yes, I think that VB is fully object oriented. In fact, its probably more OO-friendly than some other languages out there.

Jack

 

[LeonTang]

I disagree with what Jack has said. VB is not an OO language because it doesn't support OO concepts like inheritance etc. I may be wrong on this because I don't work much with Vb. So perhaps Jack can further explain as in to which of the OO principles did they use?

I have never used VFP before so I shall not comment on it

Leon

 

[JimmyK]

Leon,
VB doesn;t support inheritance but VFP does.
Yet VFP doesn;t support "Multiple Inheritance"
Jimmy Le
nhan_tiags@yahoo.com

 

[LeonTang]

So doesn't this make any sense when you said in your first post "And it is said that VB is less object-oriented than Visual Foxpro!"

However, I seriously can't think of any OO concepts that could be used in VB... waiting impatiently for Jack's response to enlighten me... hehe...

Leon

 

[hsk007]

Hi,

Thats a very interesting question. I think VB is not Object-Oriented but it is Object-Based. There is difference between Obj-Oriented and Obj-Based. In Object Oriented, we have to start our object building from scratch. But in VB we have object already built. Those are the controls on the toolbar. Only we have to do is to drag them up and create their instance. That why VB is Obj-Based. Although it supports some Obj-Oriented features. But it is not fully Obj-Oriented.

Hope this will answer your question.

hsk007

 

[JimmyK]

Hi hsk007,
VB has many built-in objects that can't say that VB is not OO!!.
I agree that VB is not fully OO in comparison with C++.

BTW, VB has Implements statement but you cant reuse code by this statement.

Real Inheritance is for code-reuse purpose. Jimmy Le
nhan_tiags@yahoo.com

 

[JimmyK]

Hi,
I give you an example

* This is code in VFP
ab =createobject("Horse&quot
ab.Eat()

Define class Animal as custom
proc Eat
? "Animal Eat"
endproc
EndDefine

Define class Horse as Animal

EndDefine
Look at that snippets. You dont have to write code for Horse.Eat

* Anh this is what i 've done in VB
'Class module Animal
Public Sub Eat
Debug.Print "Animal Eat"
End Sub

'Class module Horse
Implements Animal

I hope to create an instance of Horse but cant. An error say that "Object module need to implement Eat for Animal interface".

I search for helps in MSDN, the article "The Many (Inter)Faces of Code Reuse" say that "Implements provides a powerful new means of code reuse" . It makes me confused. I think Implements is only for Polymorphism. Is it right?


Jimmy Le
nhan_tiags@yahoo.com

 

[jmarler]

JimmyLe,
Implements is used for polymorphism, but you only inherit the interface (similar to a C++ Base Abstract Class). In the your class that implements the interface, you still need to add code specific to the class. Normally, you would not put any code in you interface definition (i.e. your animal class), Here is what your code shoule look like . . .

'**Class module Animal
Public Sub Eat
End Sub

'**Class module Horse
Implements Animal 

Private Sub Animal_Eat
    Debug.Print  "Animal Eat"
end sub

Note the the private sub Animal_Eat becomes public when an object variable of type animal is set equal to an instance of the horse class. - Jeff Marler B-)

 

[JimmyK]

Hi Jeff Marler,
Abstract class? I do know
As you said, Implements is for inheritance of interface, not code-reuse? Jimmy Le
nhan_tiags@yahoo.com

 

[jmarler]

Yes, that is correct. Implements only gets you the interface, NOT the code-reuse. That is coming with VB.Net. - Jeff Marler B-)

 

[jfrost10]

Hey Leon,
VB is very much OO. Although there's the opinion that because its so "nice and easy", its not a real programming language, blah blah. But VB does allow programmers to develop fully OO based applications. In addition, its an excellent environment for people who have never experienced OO to learn it. Here are a few points:

- VB Class Modules: VB makes it extrememly easy to create classes, use them within code, and store them as well.
- UML Integration: If you can model it with UML, you can build it with VB. If you don't believe me, I can send you a link that shows how to build an entire DLL from UML models and Rational Rose code generator.
- COM objects object integrated already: the com objects are excellent examples of how VB is OO. OO code should have two attributes: loosely coupled and highly cohesive. Take a text box in VB: you can use that code on any form, no matter what. Its an object, instance of hte Text Box class. The fact that the code can be reused in ANY application and yet has little dependance on other code shows that objects are centralized to how VB operates.

Now from an actual coding stndpoint, I'm a relative newbie. But I've spent the last year and a half studying OO analysis and design, and VB by far is the easiest language to develop in OO, even at least at a prototype level.

Jack

 

[jmarler]

jfrost10,
Everything that you said is true, however, most purists would say that VB is not OO because it does not support TRUE inheritance.
- Jeff Marler B-)

 

[LeonTang]

Hi Jack, thanks for your explanation on that. You made quite a few gd points there like due to opinion that its easy to use, it is not a real programming language. I do have that sort of impression . However, I would like to stress the point that using TextBox class etc are not part of building an OO application.

When talking about creating OO applications, we create classes according to the application needs(as in the system itself) and the TextBox class is not part of it. TextBoxes are just used to build the interface. We can definately build a project with a few forms only(no modules at all) and within it, each has their own components but this doesn't mean the application is built OO wise. Hope you get what I meant by that.

And also, I feel that not much of VB users actually touch on class modules, just pure creation of forms with components in it and the codes within the forms only. Perhaps this OO part of Vb is some sort of like an "additional" part.

I also don't feel easy in creating OO applications in Vb, perhaps due to the mindset like you have said, or perhaps I am used to programming in other languages

Leon

 

[jfrost10]

Hi Leon,
My text box example was just to show that the objects that come with vb (text boxes, button, etc.) follow the general rules when creating OO code. I understand the difference between system requirements, and just having components to add to the forms for user interface.

The sentiment you have is shared throughout many VB developers, however there are a growing number that are embracing VB's OO abilities. The class modules are not an additional part of VB, it comes standard with it. When adding a module, you get the option of selecting a general or a class. However, like you pointed out, there is a vast number of developers out there who either havn't been exposed to OO development, or have just decided to stick with older development methodologies, hence why OO and VB still aren't widely discussed/accepted.

If you're interested in seeing what can be done with VB and OO, next time you're at the local bookstore check for
VB6 Business Objects, VB6 Distributed Objects, and VB6 UML,
all by Wrox. They're excellent examples of what VB can do with OO methodologies.

I've taken Java and Powerbuilder, both "OO" languages in their own rights, but VB, for a novice programmer, is still a top choice I think for learning the OO basics and advancing with the VB IDE. Although like you said, if you've already programmed with Java, C++, etc, VB is a bit of a harder sell.

Thanks for the response,
Jack

P.S. JMarler: thanks for your response too, you've challanged me to prove that VB can, in some way, support inheritance.