Printable View
Am I the only one that has had a great deal of pain trying to figure out this OOP stuff out? :eek2:
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!
Do you have a question related to VB.NET?
I don't think it is the case that OOP is hard to learn but rather that 3GL (and below) are hard to unlearn.
OO is a terrible curse upon programmers.
Moved
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: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".vb.net Code:
It is like a finger pointing away to the moon. Do not concentrate on the finger or you will miss all that heavenly glory.
I'm interested to hear why you believe this.Quote:
Originally Posted by 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).
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
Oh yeah, but it just seems incredibly prevalent with OO.Quote:
Originally Posted by techgnome
computing.bullet(metals.silver).exists = false
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. :)
@jconway: Are you having a specific problem with some aspect of OOP?
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. :thumb:
Thanks for the reply's to all.
Bruce LeeQuote:
Originally Posted by bgmacaw
Enter the Dragon
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.Quote:
Originally Posted by penagate
Genetics and sorts of crazy talk.
I feel like telling him. "Dude, just get the job done, and forget the flashy talk"
:duck:
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
Seems to meet all of the criteria for a fad.Quote:
Originally Posted by techgnome
As you can see, there are a number of people around the forums that will be able to help you out. :)Quote:
Originally Posted by jconway
You have our gratitude. :DQuote:
Originally Posted by silentthread
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.
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.Quote:
Originally Posted by jconway
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.
That simple line of code does so much in the background...Code:APCSettings.sUserId = txtInput.Text
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.
Again - so much happens in the class with these two simple calls.Code: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)
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...
You know Steve, I think you've gone too far this time. :rolleyes:Quote:
Originally Posted by szlamany
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.
@rb - I admitted I made that mistake myself - using my old skill set. I wasn't trying to slight VB6 with that statement.Quote:
Originally Posted by szlamany
Monolithic was my choice - a design concept that I was familiar with and didn't have time to educate myself away from.
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.
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. :DQuote:
Originally Posted by szlamany
I wonder where the real problem is? :rolleyes:
LOL... If that is a true story that would really be funny. :lol:Quote:
Originally Posted by bgmacaw
Sadly, it's quite true. I used to work there.Quote:
Originally Posted by RhinoBull
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.
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.Quote:
Originally Posted by szlamany
If you organized a VB6 project carefully, then you could move the thing into VB.NET fairly easily, and it would be better.
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)?
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"...Quote:
Originally Posted by Shaggy Hiker
What in the heck does that mean, I wonder? :rolleyes:
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.
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
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.
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.
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!
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.Quote:
Originally Posted by Pasvorto
Thanks.
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.
I was hopping you could... :) Let me know when you remember what was it.Quote:
Originally Posted by Pasvorto
Thanks.
I wrote an article about this back in May: A Look at When to Rewrite Your VB6 apps in VB.NET.Quote:
Originally Posted by Pasvorto
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.
It was the M$ VB6 to .NET Upgradde Assesment Tool
http://www.microsoft.com/downloads/d...displaylang=en
Thanks Pasvorto.Quote:
Originally Posted by Pasvorto
I agree but the problem often is that senior management wouldn't listen - they simply mandate the "latest and greatest" so lots of developers won't even have a choice [unfortunately].Quote:
Originally Posted by bgmacaw
If we are talking about organizational improvements in .NET, the one I like the most is #Region. That makes it sooooo simple to shunt things out of the way temporarily.
What I meant about organization in VB6 was that there was nothing in VB6 that was keeping you from putting a few public variables in each of several modules. That could easily get a bit messy, especially if you get into name conflicts, and have to figure out where your conflict is coming from. More of a nuisance than anything else, but a nuisance is rather the point. If you have enough minor nuisances, you spend too much time doing the housekeeping. The purpose behind OO was primarily organization. Those other nice things, like polymorphism, inheritance, etc. are all very well and good, but the key to objects is encapsulating data and the methods that use the data. If you use only that feature of OO, you are certainly not using it all, but you will avoid some of the pitfalls in an aggressive OO design (like long, unmanageable inheritance trees).
Of course, you could organize a VB6 module in the same way, with private (module scope) variables, and public methods that worked on them. You could also have a single module where ALL public variables resided, which would keep them tidily organized in one place. This looks alot like the first steps into OO, but it requires discipline to organize a VB6 project that way, while it is much easier in .NET.....until we start getting into partial implementations of classes, then we can have a single class scattered across any number of files, which strikes me as being a recipe for confusion.
Partial Classes should only be used where part of the class is automatically generated code (e.g. from a wizard or codegen tool) - according to my VB2008 coding standards anyway.
You substituting new language feature with "organizing" - they are not the same.Quote:
Originally Posted by Shaggy Hiker
For me "organizing" means that everything is in place and is very easy to access
For instance, I hate new editor for one simple reason - it does not have "single procedure view" functionality like it was in pre.dot.net.
Here is what you do - open your code editor, go to any procedure and hit Ctrl+End... You know what's going to happen next - if you have large module you'll be taken at the very end of it.
Whould you call that good "organizational improvements"? I wouldn't.
To make the point:
anything you use (super nova or very old) is just a tool and YOU have to have organizational skills in order to use it properly.
If you don't have it then there is nothingin the world that would help you - Dot.Net or not it doesn't really matter.
Best regards.
AH! So now we get to the root of RB's issues... it's NOT with the language... but the IDE.
Ctrl+End - has always taken me to the end of the code... but I don't like the single proc view anyways. Ctrl+DownArrow would take me to the next proc in the code - I've found that to be helpful.... doesn't work in VS... wished it did. But I'm not going to hold a grudge against VB.NET for a failing of the IDE.
-tg
FWIT: #Region is also an IDE feature, not a language one.
How could it not be? It's a dinosaur or perhaps a Mammon if you will... Slow, bulky... :mad:Quote:
Originally Posted by techgnome
... and #Region is not an IDE feature ... ;)
I agree with that last point. I just think there are more tools. While Ctrl+End will do that for any file that I am aware of, being a Windows standard, you also have a little button that will take you right back to the very line you were at. Thus if you bounce to a different module by looking for the definition of a function, you can go right back when you want to.Quote:
Originally Posted by RhinoBull
I fail to see how #Region, which is not a language feature, but an IDE feature (no MSIL code is generated), could be considered anything other than an organizational tool. What other purpose could it serve?