How is visual basic object oriented?

My professor claims that object oriented programming is based off the objects like text labels, combo box offices etc. But is this true?

Umm... the language is object-oriented in that it supports classes, inheritance, polymorphism, etc as first-class citizens of the language.

It does not mean, however, that all code written in Visual Basic is written in an object-oriented style.

I fear you may have garbled your professor's words. Certainly, a Label control is defined by a class and instantiated as an object on a form (also an object), but there's plenty more to OO than just that. And it's not necessarily a useful distinction either. As I mentioned before, you can completely ignore the OO principles and write very procedural code in Visual Basic, should you so desire.

You can also, with a little more effort, write code in a functional style, although VB's verbosity in its syntax for where it natively supports those constructs (lambda-expressions, I'm looking at you) could make it quite a tedious exercise compared to some other languages. (As well as not giving compiler support for things such as enforcing immutability of objects, so you have to have a bit more discipline).

Text labels and combo boxes are called controls.

Not sure what you know about object oriented programming, but I'm new to programming and my course didn't explain much about it, so it probably would be a good idea to watch some Youtube videos on the subject to get a better understanding.

Is immutability anything more than a bunch of fancy terms?

Quote:

---

Originally Posted by cytotoxictcell

My professor claims that object oriented programming is based off the objects like text labels, combo box offices etc. But is this true?

---

I would say that is a 100% correct statement albeit rather simplistic. OOP is based off objects. Labels and combo boxes are definitely objects.

Quote:

---

Text labels and combo boxes are called controls.

---

Yes, and the Controls class inherits from System.Object making controls objects themselves.

What your professor said isn't wrong, but it's so simplistic it is sort of confusing.

Evil_Giraffe hit a lot of the big points in his first paragraph. I'm going to nerd out and try to make it clear. Evil_Giraffe pointed out another important thing. Often, you can use a language known for being "structured" or "object oriented" to write code in the other style. Generally, it's easier to use a language for the way it was designed.

If VB .NET were a structured language, it'd look like this:

Code:

---

Dim buttonHandle As Handle = CreateControl(ControlTypes.Button)
SetControlText(buttonHandle, "OK")
AddChild(myHandle, buttonHandle)

---

See how the emphasis is on calling Subs/Functions, and for each one I have to specify which thing I want to change? This is all over the Windows API. It turns out what's happening, behind the scenes, a lot of the trappings of OO code have been implemented but presented in an easier form. CreateControl() likely results in some "Control" Structure being generated with a note "this structure is for a button". When you call SetControlText() with buttonHandle, first SetControlText() finds that Structure and checks the control type. When it sees it's a button, it knows there's a hidden SetButtonText() method somewhere and it calls that. This is basically polymorphism, and OO languages were created because developers were tired of implementing it over and over again.

But VB .NET is OO, so it looks more like this:

Code:

---

Dim button As New Button()
button.Text = "OK"
Me.Controls.Add(button)

---

See how this emphasizes that the button is a thing, and that Text belongs to that thing? It turns out what's happening behind the scenes is Button derives from a class named "Control", which generally has a concept of Text but also knows how to paint itself. Button overrides the code for painting, so when Windows tells it to paint it knows to draw its text (along with other button-y things.) The same kinds of internal data structures are being generated as what I described above, but the way you talk about them looks a little more natural.

There's not really a functional equivalent. Functional languages tend to be very bad at UI, because UI requires "mutable state" and a very big part of functional programming is avoiding state. They certainly can do UI, but it's always really ugly and involves some fancier tricks than are appropriate for a tutorial.

But if I had to write the answer on a CS exam, I'd say what makes VB .NET OO is that it supports the four pillars of OOP with various mechanisms:

1. Abstraction is implemented via a type system that uses Classes, Modules, and Structures to organize properties and methods into logical units.
2. Inheritance is a feature of Classes and allows you to define more specialized versions of types.
3. Polymorphism is implemented via Overridable methods, and the most-derived version of a polymorphic method is always called.
4. Encapsulation is accomplished via access specifiers on Class members.

Quote:

---

Is immutability anything more than a bunch of fancy terms?

---

The idea of an immutable type is "once it is created, its values cannot change". Here's an immutable type in VB:

Code:

---

Public Structure LottoTicket

    Private _number As Integer

    Public Sub New(ByVal number As Integer)
        _number = number
    End Sub

    Public ReadOnly Property Number As Integer

End Sub

---

The reason these are important to modern development (and particularly functional languages) is you know their state can never change so they're thread-safe. I might have a million threads generating lotto tickets, but if I have some LottoTicket on my thread, there's nothing any thread or other process can do to change its Number. When you're building massively parallel systems, immutable types are a major boon for avoiding the nightmares of thread synchronization. And FP languages happen to do massively parallel systems very, very well.

There's a lot more to it, but I don't feel comfortable enough with my FP knowledge to go deep.

Why are you guys replying to a 5+ year old thread?

lol. I didn't even look at the date.

Woops. My bad.

AHHHHHHHH

The timestamp's kind of small and this rarely happens. I usually don't check.

Also because I just finished a ticket I spent a week on but it was 4:45 so not really enough time left in the day to make significant progress on the next one.

Hahaha, I love these necro-threads. :D

Smiles...

I guess, being a newcomer, GeoFrias didn't read the date either.

Pop.