[2005] why is OOP so difficult to learn?

[jconway]

Am I the only one that has had a great deal of pain trying to figure out this OOP stuff out?

I have a computer science degree from the early 80's and have worked with structured programming in C, Pascal, Fortran.... Granted I have not touched programming other then scripting, since Foxpro 2.6.

I will figure this stuff out. So help me GOD!

[Hack]

Do you have a question related to VB.NET?

[Merrion]

I don't think it is the case that OOP is hard to learn but rather that 3GL (and below) are hard to unlearn.

[penagate]

OO is a terrible curse upon programmers.

[Hack]

Moved

[jmcilhinney]

OOP is extremely easy to learn but people just don't look at it the right way. They keep trying to understand it in an abstract way instead of accepting the fact that programming objects are modelled on real-world objects. Basically any OOP problem can be explained with a good real-world analogy, which most teachers and teaching resources seem to neglect.

For example, someone posted today that they had a form with a ComboBox on it. They wanted to call a method on that form that cleared the ComboBox but when they did so nothing happened and they were confused. Their code looked something like this:

Dim f1 As New Form1
 
f1.ComboBox1.Items.Clear()

My analogy was this. If you have a car that has no petrol and you want to fill it up, would you buy a new car and fill its petrol tank and expect the existing car to be filled? The answer is "no". If you get a new object and do something to it that doesn't affect any existing objects. The same is true of programming objects. If you have an existing Form1 object and you create a new Form1 object and clear its ComboBox, would you expect the existing Form1 object and its ComboBox to be affected? The answer is again "no".

[bgmacaw]

It is like a finger pointing away to the moon. Do not concentrate on the finger or you will miss all that heavenly glory.

[Hack]

OO is a terrible curse upon programmers.

I'm interested to hear why you believe this.

[penagate]

My posts in this thread, taken with a pinch of salt, kind of summarise my views on OO; although they've changed slightly since then (they do all the time).

In a nutshell, my opinion is that OO in itself is not entirely bad; rather, it is the industry's obsession with it at the expense of using more appropriate paradigms that I am opposed to (although there are many elements of OO itself that I dislike as well, as detailed in that thread).

It is a fad, and hopefully common sense prevail and its use will eventually begin to diminish (just to be overtaken by the next fad, I suppose).

[techgnome]

I agree with penagate.... but that's true of any technology... it shouldn't be done for the sake of being done. It needs to be applied appropriately. Hammers aren't necessarily bad, when used right (hitting nails), but when it's used "because I could" (getting keys out of a locked car, swatting flies)... that's when the trouble starts.

The reason most people have issues with OO is because of its misuse. I have issues with it because people see it as this great panacea and don't / can't / won't recognize that there are sometimes when it just doesn't make sense.

-tg

[penagate]

I agree with penagate.... but that's true of any technology... it shouldn't be done for the sake of being done.

Oh yeah, but it just seems incredibly prevalent with OO.

[Merrion]

computing.bullet(metals.silver).exists = false

[RhinoBull]

I most certainly agree with Pen as well - OOP can become very violent instrument if not properly used (even in dot net where everything is object).

But I wouldn't say it's difficult to learn either.

[Hack]

@jconway: Are you having a specific problem with some aspect of OOP?

[jconway]

No, just venting a little. I just wanted to see if I was the only one that thinks this OOP is hard.

I really don't think it is that hard, just very confusing. So many options in the .net environment that it is hard to tell what is what.

I will be asking questions as I develop my skills.

Thanks for the reply's to all.

[silentthread]

It is like a finger pointing away to the moon. Do not concentrate on the finger or you will miss all that heavenly glory.

Bruce Lee
Enter the Dragon

[silentthread]

My posts in this thread, taken with a pinch of salt, kind of summarise my views on OO; although they've changed slightly since then (they do all the time).

In a nutshell, my opinion is that OO in itself is not entirely bad; rather, it is the industry's obsession with it at the expense of using more appropriate paradigms that I am opposed to (although there are many elements of OO itself that I dislike as well, as detailed in that thread).

It is a fad, and hopefully common sense prevail and its use will eventually begin to diminish (just to be overtaken by the next fad, I suppose).

I agree that it's a fad thing. This college grad started at my job recently, and he thinks he is cooler than everyone because he flashes his OOP talk around.
Genetics and sorts of crazy talk.

I feel like telling him. "Dude, just get the job done, and forget the flashy talk"

[techgnome]

Ugh.... OOP isn't a "fad" and it's been around for decades. It's nothing new.... I've been using OO concepts since at least 1989 (when I first learned of it), and it wasn't new then either. It's just that it's been taken to a whole new level. Managers have jumped all over it, thinking it's the latest (it isn't) that it'll solve all their problems (it won't) and that it's the greatest thing since sliced bread (sliced bread is great, but a gilled ham and cheese is even better).

OO isn't going anywhere.... but it may have hit critical mass... geezes, I hope so... there's a OO bubble forming and it's going to pop at some point, contract, correct itself and stablize.... theren there will be a whole new consept for people to pick their banner up for, and it repeats....

-tg

[penagate]

Managers have jumped all over it, thinking it's the latest (it isn't) that it'll solve all their problems (it won't) and that it's the greatest thing since sliced bread (sliced bread is great, but a gilled ham and cheese is even better).

Seems to meet all of the criteria for a fad.

[Hack]

I will be asking questions as I develop my skills.

As you can see, there are a number of people around the forums that will be able to help you out.

[bgmacaw]

Bruce Lee
Enter the Dragon

You have our gratitude.

Here's another one, this one from Kodo Sawaki

The pine's shadow is dark
Exactly as the moonlight is bright.

It's amazing how much OOP these zen masters knew.

[szlamany]

Am I the only one that has had a great deal of pain trying to figure out this OOP stuff out?

I have a computer science degree from the early 80's and have worked with structured programming in C, Pascal, Fortran.... Granted I have not touched programming other then scripting, since Foxpro 2.6.

I will figure this stuff out. So help me GOD!

I come from a mainframe programming background - since the 80's as well. I've developed some huge monolithic programs - general maintenance programs - general report writers - RDBMS database systems (although this used OO concepts even though I was unaware of the term). All on mainframes.

When I first started in VB6 back in 2000 my first large scale task was to develop a general maintenance program. I used all I knew at the time - my old skill set.

This resulted in a basMain with 22,000 lines of code. I was at least smart enough to make my form events call functions in the basMain (this is a huge mdi app for maintaining application data and reporting on it).

But here I am with this huge monolithic basMain - dozens and dozens of public variables - public arrays. It's extremely hard to enhance - and I understand all the reasons for that.

Now I develop new app's in VS2005 - latest one for a pocket pc. And I'm trying to use OO techniques as much as possible.

For instance - need to know the username, server and database that the PPC will attach to on the network. Back in old days you would make these public variables. But you also need to have them stored in a file. So you would have code in your basMain to manage all that. Now in a class - when it's created - it opens the file and loads private vbl's in the class with these values. The class exposes these values as properties. Change the value through the property and it writes it to the file. All hidden from the main app.

APCSettings.sUserId = txtInput.Text

That simple line of code does so much in the background...

Another example - need to manage a pile of UI runtime aspects - and what queries are run to serve up those UI experiences. In the past - you would manage a bunch of arrays and pointers to those arrays - all in main code. Now with class concepts - all that is hidden. The class "knows" how far down the GUI has drilled - what queries are needed to serve that level of drill-down. If (and they do) the queries get more complex - you only need to enhance code in the class. The calls to the classes properties and methods stay nearly static from the main app.

If Deeper Then
    APCCtrl.QueryLevel = 3
Else
    APCCtrl.QueryLevel = 2
End If

Dim qs As String = APCCtrl.QueryString(lblWhat.Text, txtInput.Text, strData, strTag, lst)
Dim qn As String = APCCtrl.QueryName(strData, lst)

Again - so much happens in the class with these two simple calls.

I am thoroughly satisfied with using OO - it's made complex program design so much easier. It's all about compartmentalizing your code - and that's a good thing. I'm sure I'm not using OO 100% according to the "learned" doctrine - but this is the real world - and it's helping me produce faster code that's easier to understand, maintain and enhance.

I could care less about the buzzwords (actually that's not really true - I really enjoy reading the threads in the .Net section - especially those by JM when he's willing the teach )

I can't wait till we have the time in-house here to re-develop that ugly monolithic VB6 app in VS2005...

[RhinoBull]

I can't wait till we have the time in-house here to re-develop that ugly monolithic VB6 app in VS2005...

You know Steve, I think you've gone too far this time.
Seriously, it could be ugly (architechture wise) because you designed it that way.
And how is VB6 apps are [as you say] monolithic ?! You're being very subjective and not realistic. Common, enough is enough.

Thank you.

[szlamany]

... VB6 back in 2000... I used all I knew at the time - my old skill set.

@rb - I admitted I made that mistake myself - using my old skill set. I wasn't trying to slight VB6 with that statement.

Monolithic was my choice - a design concept that I was familiar with and didn't have time to educate myself away from.

[RhinoBull]

Everybody knows you made a mistake but you just don't have make everybody feels your pain.
And I know that you weren't "trying to slight VB6" but it sounded just like you did so maybe you want to read it over once before submitting your replies.
Your last reply is much more objective as it should be - there are many members that cannot afford (for many different and obvious reasons) to use .Net yet.

Sorry.

[bgmacaw]

I can't wait till we have the time in-house here to re-develop that ugly monolithic VB6 app in VS2005...

At one company I know of they redeveloped an ugly, monolithic, VB6 app into an ugly, monolithic, VB.NET app. Now they've decided that VB.NET sucks so now they're working on an ugly, monolithic, C# app.

I wonder where the real problem is?

[RhinoBull]

At one company I know of they redeveloped an ugly, monolithic, VB6 app into an ugly, monolithic, VB.NET app. Now they've decided that VB.NET sucks so now they're working on an ugly, monolithic, C# app.

I wonder where the real problem is?

LOL... If that is a true story that would really be funny.

[bgmacaw]

LOL... If that is a true story that would really be funny.

Sadly, it's quite true. I used to work there.

Combine a development manager who only believes in doing things the quick-and-dirty way and 'chief architect' who is pretty much incompetent programming-wise but is politically astute at CYA and backstabbing and that's what you get.

[Shaggy Hiker]

@rb - I admitted I made that mistake myself - using my old skill set. I wasn't trying to slight VB6 with that statement.

Monolithic was my choice - a design concept that I was familiar with and didn't have time to educate myself away from.

I agree with the idea. I wrote plenty in VB6, and tried to make it as close to OO as VB6 was capable of going. After all, modules could be made to work like classes after a fashion. Still, the advantages of OO in a simplified fashion is sufficient that if I were to slight VB6....well, I won't deny it. I loved that language, but when .NET came along, I left it behind and have never willingly returned to it.

If you organized a VB6 project carefully, then you could move the thing into VB.NET fairly easily, and it would be better.

[RhinoBull]

I don't think that anyone can argue the fact that .Net is way much more powerful than pre.dot.net products.
The problem comes when people start bashing and slashing VB6 which is not fare from any point of view.
Why don't people compare Win 3.1 and Vista or say Win 3.11 Groups (or whatever the name was) and Windows Server 2003 (or up comming 2008)?

[Shaggy Hiker]

I wouldn't say I would bash VB6, because it was wonderful in its time, but I wouldn't go back, just as I wouldn't return to Win 3.1.

However, the analogy stops there. In a large VB6 project, you had to be a bit careful or you would get masses of disorganized Public variables causing problems around the place. Perhaps you have a global that indicates something significant and one piece of the program changes it, but so does another, which was written much later. Will the two conflict? Maybe. You had to be a bit careful to avoid things like that. One way to do so was to not use Public variables (or VERY few), but to use Private variables in a module, and expose them through public subs or functions in the module. If you did something like that, you have created a class. The variables are protected, and access to them is only through functions (properties in .NET, though methods could also be used).

There are probably other ways to organize a VB6 program, but since I used the method listed above, the move to .NET wasn't so much radically different, but formalizing into the language what I was doing informally.

[RhinoBull]

I wouldn't say I would bash VB6, because it was wonderful in its time, but I wouldn't go back, just as I wouldn't return to Win 3.1.

However, the analogy stops there. In a large VB6 project, you had to be a bit careful or you would get masses of disorganized Public variables causing problems around the place. Perhaps you have a global that indicates something significant and one piece of the program changes it, but so does another, which was written much later. Will the two conflict? Maybe. You had to be a bit careful to avoid things like that. One way to do so was to not use Public variables (or VERY few), but to use Private variables in a module, and expose them through public subs or functions in the module. If you did something like that, you have created a class. The variables are protected, and access to them is only through functions (properties in .NET, though methods could also be used).

There are probably other ways to organize a VB6 program, but since I used the method listed above, the move to .NET wasn't so much radically different, but formalizing into the language what I was doing informally.

You keep saying "organizing, organizing and organizing VB6 projects"...
What in the heck does that mean, I wonder?
How is it different from "organizing .Net project" or say Java project or whatever project?

I wish you would explain it like a pro-to-pro and not pro-to-newbie. Sorry for this "pro" stuf but I couldn't come up with anything other than that.

Thanks.

[techgnome]

Here's an organizational thing I can do in .NET that I can't do in VB6: Namespaces. I like the fact that I can add namespaces to my classes, giving them a logical organization. That's not something I could do in VB6. Yes I know NS add some verbosity to the code, but at least I know that all of my data access classes can be found at app.Data.Database.DataAccess .... and that my business logic classes can be found in app.Data.Business.Data. And all my database connectivity is handled by app.Data.Database.AppDatabase.

I also like the ability to create regions and collapse them. OK, so that's not a feature of .NET inherently, but it's still something that's missing in the old VB6 IDE.

RB -you're right, it isn't fair, but neither is blindly pushing a technology for the sake of pushing it. The zealots work both ends of the arguments. While I don't see anything wrong with VB6, I see a lot of room for improvement. And much of that is accomplished with VB.NET. If VB7/8 had just been simple updates, and not a complete overhaul as was done, we'd still be using it as our primary platform.

The "don't want to switch to .NET" camp (and this is my own personal observation) is made up of two types: Those who have been working in VB for so long and don't really want to have to change a thing. 30yrs ago they would have been called COBOL programmers. The other group is the newbie group that were only taught (badly) VB6. They only know of one way of doing something, as they were taught, and don't necessarily have the skills to cope with the changes. It's not necessarily a reflection of their ability directly, just a lack of experience or ineffective teaching (those who can, do. Those who can't, tech - or sometimes are promoted to management, which usually explains other problems found in the software development industry.)

-tg

[RhinoBull]

Namespace is not "organizational thing" - it's rather convenient thing. And you can create your own "namespace"...
I switched (as you say) to .Net when first Beta came out back in what 2001? But I still continue to work with VB6 as wel as VC++ 6 and other languages.
VB6 was a lot of fun and .Net is not as far as I am concerned simply because lots of things are given so "programmer" doesn't have to think too much how to make something happen.
Is it more powerful? Of course it is. Does it have more than 400K objects? Sure!
But is OOP always justfied? No, no and no! And that's the end of story. Again, as far as I am concerned.

[szlamany]

I'm so sorry if I was responsible for this becoming a VB6 thread - I certainly didn't mean to bring VB6 into this!

The thread starter wanted to know about OOP being so difficult - and from my perspective I feel I know where they are coming from - as I am not by experience an OOP-knowledgable developer. It's only now that I'm using .Net that I want to adhere to those concepts - [edit] and only where they are beneficial and appropriate.

[Pasvorto]

I don't know if I am in a unique situation or not. I am a one man shop. I have about a dozen apps written in VB6. I have moved 3 of them (small, simple) to VB2005.

I have made the committment that all new development will be in VB2005. Because it is still new to me, it forces me to look at the design more that I would with VB6. I just finished a new system that runs on a barcode scanner running Windows CE. Very easy to do in VB2005. OOP? I really can't say. Too simple.

Two of the remaining apps are huge (IMHO). The largest is about 300,000 lines of VB6 code. I have nightmares about converting it to VB2005. "Don't convert... rewrite." OK. I can accept that. If I was in a shop where that was my only project, sure, why not? Long term job security. However, when I am trying to maintain all the other systems, as well as be the help desk network admin, database admin, , etc.. I really don't have the time to bring it up to VB2005. The others are smaller, but not much.

I have 10 years until I retire. We may still be running VB6 (non OOP) apps then.

BTW, I ran the M$ conversion simulator on the big system. It predicted over 10,000 man hours. That is over 6 years! And that's if I worked it fulltime!

I'm gonna be busy!

[RhinoBull]

...I ran the M$ conversion simulator...

Just out curiosity, what is that? I mean, I can do quick research but I'd rather hear it from someone who actually used it.

Thanks.

[Pasvorto]

Sure, now you're going to make me try to remember what I did. The process was easy. I ran the program (which I can't seem to remember right now). It gave me a report with the conversion effort.

[RhinoBull]

... I ran the program (which I can't seem to remember right now)...

I was hopping you could... Let me know when you remember what was it.

Thanks.

[bgmacaw]

Two of the remaining apps are huge (IMHO). The largest is about 300,000 lines of VB6 code. I have nightmares about converting it to VB2005. "Don't convert... rewrite."

I wrote an article about this back in May: A Look at When to Rewrite Your VB6 apps in VB.NET.

My key point was not to rewrite just to rewrite. As long as the app is working fine and is maintainable there's no need to do it. But, if the app is showing some warning signs then it might be time to consider a rewrite.