Smart questions
Smart answers
Smart people
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Member Login




Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

IronRocket (TechnicalUser) (OP)
7 Dec 07 10:27
Just wondering if it's just me.  I recently took a .net class and got a "B" in it.  I learned some OOP in it and I felt I hit a brick wall.  For some reason I think I have a mental block in where I can't understand OOP that well.

I've read it over and over again...if I keep my mind from drifting...I still don't understand the concepts.  Just wondering if anyone has had the same problem of learning this stuff or if I'm plain stupid.
lespaul (Programmer)
7 Dec 07 10:52
Join the club!!!!  However, don't give up...I'm FINALLY starting to GET IT!  I've been programming in Delphi for about 5 years and never really took advantage of some of the OOP techniques that I could have.  I found this site specific to OOP in Delphi that REALLY helped me (I wish I had found it a LONG time ago!).  But if you don't know Delphi it probably won't help you quite as much.

However, one of the reasons that I have been trying to learn more about OOP is because we are converting to a Java shop and I'd like to implement the class structure and the OOP correctly.  Here's another Java OOP site that I found that helped me overcome some of my mental blocks on OOP in general:

http://java.sun.com/docs/books/tutorial/java/javaOO/classes.html

I've also done some lurking in forum678: Object-Oriented Analysis & Design and there are some threads there that helped.  One of the most helpful examples for OOP (about TBug, TInsect and TSpider) was given to me in thread102-1428280: SetFocus/OnExit (it's way at the bottom past the horrible coding issue).

Leslie

In an open world there's no need for windows and gates
www.ubuntu.com

CajunCenturion (Programmer)
7 Dec 07 11:11
OOP can be difficult to get your arms around, especially if you're originally a procedure oriented programmer.  You're not alone.  It's a different paradigm, but as Leslie says, don't give up because one day, all the pieces will drop into place.

--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886: How can I maximize my chances of getting an answer?
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

IronRocket (TechnicalUser) (OP)
7 Dec 07 11:16
Thank you very much!  I went through some of the threads, and I am seeing that I'm not the only one that is struggling with it.  I thought I was stuck on stupid.  Thanks again.
Helpful Member!  DonQuichote (Programmer)
9 Dec 07 8:37
When I was young, I got a tape recorder. It came with a large (A1 format) electrical scheme. This scheme contained the entire design of the machine: engine control, amplification, tone control (2 times, because it was a stereo machine), etc.

If you open a modern video recorder, you will see something entirely different. There are large components (subassemblies), like a preamplifier module, an engine control module, etc. that are clicked together with plugs.

History went the same for programming. We started with languages like GW-Basic, which were one "recipe" containing everything. But we now have object-oriented languages that allow us to do things in modules (called classes).

Mind you, there is absolutely nothing you can do with object orientation that you cannot do otherwise. You could build a video recorder in just one scheme as well.

So why do we do things in a modular fashion?
  • Because it's less work. This sounds really strange. Designing every component with plugs is extra work. However, if it is done correctly, you can reuse such a component. If you designed a preamplifier module for a CD player, you can use the same component in an MP3 player, a computer, a video recorder, your navigation system, etc. Also, a well-difined plug allows you to outsource such a component or use a ready-made one. The same thing applies to, say, a Database class.
  • Because it is testable. If the only signals that a component receives come in trough the plug and come out through it, you can feed that component a known signal and check for the known output. It is quite normal for bought electronic components to be tested before they are built in. However, "unit testing" in software development is still a rare phenomenon. Strange.
    By the way, this will only work if there are no hardwired connections between modules and everything really goes through plugs. The "Law of Demeter" guides you to design your classes well in an object-oriented application.
  • Modular components have little impact on the rest of the structure. This comes from the fact that a plug usually defines an abstract function. A sound plug only tells you that a device produces or consumes a sound signal. It does not tell you how it is generated. The same plug is found on a CD player, a cassette player, etc. Your wall power socket does not care what you connect to it as well, as long as it behaves correctly. This means that a plug is recongizable, and that components have a responsibility. Google for "Design by Contract" if you want to know more on this.
  • Modules are much easier to maintain. Due to their limited implact on the rest of the design, their clickable nature, and their coverager of only a part of the functionality, they can eaily be repaired or replaced. What's more, you don't need to know the insides of a component. The plug tells you enough.
  • The responsibility allows a component to do its own optimization. A clock card in your PC might have its own battery, for example. Or a Database class may only open a connection when one is needed.
Now wait. Do objects have plugs then? Certainly. They are called the interface of the object. The interface consists of all accessible methods and properties (including the constructor). To be recognizable, you should therefore always used meaningful names for methods.
(Do not confuse this with the interface keyword in a lot of languages, which defines a restriction on the interface of an object: the interface should have at least these methods)

Off course, there is a lot more to tell, but this is probably complicated enough already. I hope it clarifies some things.
macleod1021 (Programmer)
11 Dec 07 13:24
There's a Head First book out there (can't remember the exact name atm) that had a pretty good way of explaining things. It looks like it's a huge book but there's a lot of pictures and diagrams to help reinforce the subject matter.

I agree with everyone else...don't give up. Once it clicked for me, I couldn't believe the differences in my code.
LNBruno (Programmer)
11 Dec 07 16:14
Two (thin) books which really helped me by David A. Taylor:

1)  Object-Oriented Technology:  A Manager's Guide
2)  Business Engineering with Object Technology

< M!ke >
Holidays cause stress.  Crazy people crack under stress.  Consider yourself warned.

xwb (Programmer)
11 Dec 07 16:22
Try writing a simple game.  It is your game: no constraints, no deadline and you can make as many mistakes and have as many rewrites as you like.

I picked a game from the Commodore PET called seige.  One defender, a castle wall, a missle and several attackers.  The defender throws missiles at the attackers.  If it hits, the attacker falls and takes down any other attackers in the way.  Work out the objects, commonalities, how to draw them, how they move.  Stick them in a nice merry loop and away you go.  I've done the same program in C, Pascal, C++, VB, PL/M and Fortran while trying out techniques and learning languages.  What's good is that you get to play the game at the end of the day.  Something completely mindless like tetris but it is fun because you wrote it.

Yes - you can do OOP with a non OO language.  Languages without structs like BASIC are a bit more difficult.
gbaughma (IS/IT--Management)
12 Dec 07 11:35
90% of what I program is OOP.

"Oop!  Why didn't that work!  OOP!  Forgot to define the variable... OOP!  I just cut a chunk out of the wrong routine....."

rofl

Just my 2ยข
-Cole's Law:  Shredded cabbage

--Greg  http://parallel.tzo.com

CajunCenturion (Programmer)
12 Dec 07 12:59
==> 90% of what I program is OOP.
Is that an example of inheritance?

--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886: How can I maximize my chances of getting an answer?
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

xwb (Programmer)
13 Dec 07 3:32
When does it change from OOP to OMG?
lespaul (Programmer)
13 Dec 07 9:30
when you extend the class....

rofl2
wlemery (Programmer)
13 Dec 07 15:27
Yeah, what they said. Don't give up on it, it isn't easy, and you're not alone in this. When I was learning OOP I felt dumber than a box of rocks. It seemed to me everyone understood this concept except me. Then after I got over the hump, so to speak, I realized that I wasn't alone at all.

The real strength of OOP is subclasses and inheritance. I think it's worth mentioning that Micro$oft misused these terms to describe Visual Basic 6 as an object oriented language, and it isn't - you can't subclass in VB6.

If you know C, get a copy of C++, write your own base class of any kind and subclass it about four levels deep. Play around with it a little and you'll catch on.

Helpful Member!  lionelhill (TechnicalUser)
18 Dec 07 13:53
There's another barrier to OOP that sits in the heads of some of us.

If you date back to the era when a really fast processor went at 2Mhz instead of 1Mhz, performance really mattered.

Most OOP explanations usually start defining some simple object like a point in graphics. They define a few methods for tasks such as moving the point around the screen. Then they define a square as four points. At this point the 1Mhz-processor-programmer starts getting mild doubts because s/he is busy wondering why we've used 8 numbers (4 sets of coordinates) to define something that only needed 3 numbers (the position of the square and how big it is). We're aware that memory isn't so important nowadays as it was when we had 512 bytes (yes, that was how much I had when I first wrote a program), but we can see where this is going...

Now the OOP book gets very excited, by telling us that square.move will work just like point.move and we don't need any new code to move the square.

This is where the 1Mhz-programmer gets really upset, because s/he is painfully aware that we're now making 4 calls to change 8 numbers, whereas we only needed 1 call to change 2 numbers. We have quite probably quadrupled the time taken to carry out the task (possibly not quite so bad bearing in mind caching issues of modern processors etc.). The worst of it is that in the high level code, we haven't even got the faintest hint of what's going on behind the scenes, so we aren't being warned that our code is inefficient. This feels wrong, all wrong...

If anyone out there can come up with a simple teaching example of OOP and inheritance that isn't blatantly and automatically less efficient than a simple procedural equivalent, I'd be very grateful, and I'm sure I'm not alone.

Obviously programmers' time is important, but so is users', and high-performance programming is still quite valuable when the task is large and the machine is old.
chrissie1 (Programmer)
18 Dec 07 15:09
The right tool for the right job comes to mind. So lionelhill I think you are trying the wrong tool.

OOP comes to it's own in multi-programmer environments were code maintainability and readability is more important then getting the last millisecond out of it. If you work with a group of programmers on the same product then interfaces are a godsent and getting someone up to speed will be faster to.

But for the rest it is a senseless discussion like the one between Java and .Net. And who cares anyway, just get the job done. If they want OOP then better for me, if not then I'm out.

And I hate web-development, talk about hacking to get things done (like: it works on IE10,11 and 13 but not 11a or 12 sorry).

Christiaan Baes
Belgium

My Blog

Glenn9999 (Programmer)
18 Dec 07 16:31

Quote (lionelhill):


If anyone out there can come up with a simple teaching example of OOP and inheritance that isn't blatantly and automatically less efficient than a simple procedural equivalent, I'd be very grateful, and I'm sure I'm not alone.

That is the major issue, among many.  While I understand the concept of OOP, the problem (as I stated in another thread made at this same time) really is to demonstrate any value in OOP over the procedural methods.  

In addition to the adding of code/complexity, the question comes of knowledge - OOP makes it so easy to create black-boxes of which the user of said black-box knows nothing of it, and is clueless as to its function.  Add to that, that many of the black-boxes are poorly made, hard to use (thinking the Delphi VCL here) and have to be rewritten.  Additionally, the code bloat is phenominal (thinking EXE size, which reflects upon code executed) - all it takes is comparing a Delphi VCL program with a Delphi Win API program to see this difference.  In fact, I've taken to compressing most of the Delphi VCL execs anymore because they are so big.

Of course, we are in the days of the Microsoft development methodology.  As long as it works, it's fine.  If it's slow, you can always upgrade the memory and the CPU.  If the code bloat is too much, upgrade the hard drive.  And if it borks the system, well you can always reboot.

How business readily and cheerfully accepts this out of software development is still a mystery to me.
chrissie1 (Programmer)
18 Dec 07 16:48

Quote:


In addition to the adding of code/complexity, the question comes of knowledge - OOP makes it so easy to create black-boxes of which the user of said black-box knows nothing of it, and is clueless as to its function.

Sorry but if you say this then you clearly didn't understand the concept of OOP.

Christiaan Baes
Belgium

My Blog

Glenn9999 (Programmer)
18 Dec 07 19:36

Quote:


Sorry but if you say this then you clearly didn't understand the concept of OOP.

I believe this has descended to the level of holy war now and has gone far beyond any professional level.  Windows vs. Linux, IE vs. Firefox.  Now this.
CajunCenturion (Programmer)
18 Dec 07 19:37

Quote:

OOP comes to it's own in multi-programmer environments were code maintainability and readability is more important then getting the last millisecond out of it. If you work with a group of programmers on the same product then interfaces are a godsent and getting someone up to speed will be faster to.
These tried and true development methodologies and standards were developed along with good software engineering practices in the sixties and seventies - long before OOP came into being.

And thank you, but I do clearly understand the concept of OOP.   I understand well to know that not only is it not the panacea that many make it out to be, but why that is the case.  For example, let's look at encapsulation and polymorphism.  On the one hand, OOP enthusiasts touts the value of encapsulation, shielding the inner-workings of the object, thus saving the programmer the need to be concerned with inner behavior details.  On the other hand, others extol the benefits of polymorphism, providing flexible object foundations that programmers can inherit and customize to desired behaviors.  So right off the bat you have a trade-off decision to make about the opposing attributes of encapsulation and polymorphism.  Should you focus on small, stable, and encapsulated objects, or large, open, and flexible objects?  Probably you're somewhere in between, getting the best of both worlds, but at the same time, you're getting the worst of both as well.

Any experienced software developer should be able to tell you that the cost of modifying a program is nothing compared to the cost of modifying the database.  Similarly, the cost of modifying a program is considerably less than modifying your object foundation.

There are some real advantages to OOP, but there are also drawbacks.  Sometimes the best data structure for an application is an array, sometimes a stack, sometimes a queue or deque, and sometimes a tree.  And yes, sometimes an object is best.  I think wise programmers know when to use objects, and when not to.

--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886: How can I maximize my chances of getting an answer?
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

chrissie1 (Programmer)
19 Dec 07 2:26
Like I said.

Quote:


But for the rest it is a senseless discussion like the one between Java and .Net. And who cares anyway, just get the job done. If they want OOP then better for me, if not then I'm out.

Christiaan Baes
Belgium

My Blog

lionelhill (TechnicalUser)
19 Dec 07 8:46
Oh, yes. Sorry, didn't mean to start a "OOP good or bad" discussion. Really I meant just what I said: it would be easier for some of us to get the motivation to think in OOP if the book authors could come up with some more inspiring and robust examples.

Also the problem of badly-implemented black boxes isn't confined to OOP. A good old-fashioned procedural library is also just a collection of black boxes, which may or may not be efficient.

OOP is weird to humans at first sight because it's very noun-based, and humans (programers in particular) are people that do things. We're verb-based. When I try to imagine what verb-based "OOP" ("AOP, action orientated programing??") would look like, I only end up with OOP anyway, because my verb "move" has to change depending on whether it's moving a cat, a paperclip, or a data file.
Helpful Member!  AlexCuse (Programmer)
19 Dec 07 9:36
lionel - Your comments brought this to mind

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

lol

----signature below----
I'm pushing an elephant up the stairs

My Crummy Web Page

CajunCenturion (Programmer)
19 Dec 07 10:57
That's great - thanks AlexCuse.

--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886: How can I maximize my chances of getting an answer?
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

lespaul (Programmer)
19 Dec 07 12:17
that was great Alex!

Leslie
lionelhill (TechnicalUser)
27 Dec 07 12:51
Alex, you've made my day. Possibly my year. What a wondeful blog. I was a bit worried about my last post because I thought it made me look like a weirdo having a rant.

I remember looking at bees, many years ago, who make a dance to show other bees where nectar can be found; it made me wonder what it would be like to use a language based entirely on prepositions. Actually it was very dehumanising (but probably quite beeising; who knows?).

Are there any languages that allow you to define a method without first specifying the objects on which it is to operate? It definitely could be done...
DonQuichote (Programmer)
27 Dec 07 17:45
Sure. Most OO languages allow them. They are called static methods ("Shared methods" if you do VB .NET). Traditionally, Mathematical functions are often programmed as static methods of a static Math class.

Non-pure OO languages often have plain old functions as well.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close