Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What's the BEST way to really understand OOP? Any video's/Screencasts that you would recommend?

share|improve this question
6  
The C++ one? The Delphi one? The JavaScript one? –  mbq Sep 15 '10 at 23:03
5  
The Smalltalk one? The CLOS one? –  Frank Shearar Sep 30 '10 at 12:03
1  
@missingfaktor You apparently haven't been at programmers.se much: meta.programmers.stackexchange.com/questions/105/… –  TheLQ Oct 19 '10 at 1:29
    
@TheLQ: Yes, you guessed it right. I am new here. Thanks for the link. :) –  missingfaktor Oct 20 '10 at 3:09
    
Do you not understand OOPs? –  acidzombie24 Nov 1 '10 at 20:58
add comment

closed as not constructive by Jim G., Yannis Rizos Aug 15 '12 at 4:04

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

11 Answers

up vote 27 down vote accepted

The best way to understand anything is to teach it. I finally understood OO (about 20 years after I first started doing it) when I had to explain and justify why certain things were the way they were, to a class full of students.

share|improve this answer
5  
+1 because that is a very true statement. –  WalterJ89 Sep 25 '10 at 15:17
5  
I used to have a teacher that taught us: Understanding it isn't enough. When you're able to explain it to someone else that doesn't get it is when you actually understand it (and get an A). –  Robert Koritnik Oct 11 '10 at 11:08
1  
if you can't do it, you can't teach it...correctly! –  Steven A. Lowe Dec 5 '10 at 3:06
    
This is why an understanding partner is vital. Just be careful, my wife eventually realized that the sooner she 'understood' the sooner she could change the subject to dish sets or bedding or something that goes in the kitchen. –  Steve Evers Dec 5 '10 at 4:36
add comment

I was taught at the very beginning like this (I'm going to pretend reflection doesn't exist):

Classes are like blueprints: You can't use the blueprints as your house (Eg using house plans as your house), but you can use it to build the house. Here you define what the house does.

Methods are like appliances: They do a specific task and exist in the blueprints. You have a microwave, an oven, and a stove. You use the microwave to defrost many things, but you take each of those things you defrosted (the result or returned value), and do something else. You might pass it to the oven or the stove, or you might not do anything with it.

Constructors are the installers for the appliances: They set everything up but don't actually use the appliances. They plug in the microwave, stove, and oven; and put food in the cabinet.

Objects are the house: You have the house, and now you can do whatever was defined in the blueprints. If you want to use the washing machine, then you call the washing machine method. If there is no washing machine, then you need to edit the "blueprints" an add one.


You can obviously expand on the examples above, but thats a nice way to introduce OOP to someone who has never done it before. To someone transitioning from procedural or functional languages, you probably don't have to dumb it down as much, but you can still use this example

share|improve this answer
    
Best example I've heard, although I wonder what state looks like: bool StoveIsHot? –  Robert Harvey Sep 16 '10 at 1:40
    
And once you touch StoveIsHot, will you learn not to touch it again? –  RationalGeek Oct 11 '10 at 19:50
add comment

Think of software as a machine or assembly line that exists inside the computer. Some raw materials and components are fed into the machine, and it follows a set of procedures to process them into some final product. The procedures are set up to perform a specific operation on some raw material or component to a specific set of parameters (eg, time, temperature, distance, etc) in a particular order. If the details of the operation to be performed were incorrect, or the machine's sensors aren't correctly calibrated, or if some raw material or component wasn't within expected quality standards, it could change the operation's outcome and the product would not turn out as expected.

Such a machine is very rigid in its operation and acceptable inputs. Machines don't question the designers' intelligence nor its current operating environment. It will continue to follow procedures as long as it's directed to. Even if a change in raw materials or components could have a dramatic effect on what happened in later operations, the machine would still perform its procedures. The process would need to be reviewed to see what changes to the procedures were necessary to compensate and produce the desired result. A change to the product's design or configuration might also require a significant change to the operations performed or their order. Although those in charge of production quickly learned the importance of isolating operations as much as possible to reduce undesirable effects between them, a lot of assumptions are made of the condition components are in as they undergo processing; assumptions that might not be detected until the final product is in the hands of the user in some different operating environment.

That's what procedural programming is like.

What object-orientation provides is a way to remove the assumptions of the condition of components; thus, the operations to be performed on that component and how to integrate it into the final product. In other words, OOP is like taking the process details for dealing with some particular component and giving it to a smaller machine to do. The larger machine responsible for the process tells the component-specific machine which operation it expects to be done but leaves the details for the steps to the component-specific machine to handle.

share|improve this answer
add comment

The best way is thinking of using OPP to deal with changing requirements. When requirements are changed, OOP helps me dealing with minimum effort in modifying codes.

(sorry for my poor English :)

share|improve this answer
add comment

Do It

you cannot learn to swim by reading about fish; you've got to get in the water.

share|improve this answer
3  
Not only that, but most of us humans (unless you learned like the Man from Atlantis) don't swim the same way that fish do! –  GreenMatt Jan 28 '11 at 3:02
add comment

I would suggest reading the book by Bertrand Meyer "Object-oriented software construction"

share|improve this answer
add comment

For me it was Head First Java which taught be what exactly OOP is.

share|improve this answer
    
+1 I learned OOP from that book too, though I think the Head First obsession with ducks can't be healthy (they use duck metaphors a lot in Design Patterns as well). –  CodexArcanum Nov 1 '10 at 15:01
    
Ducks are fun! ;-) we are a little obsessed. –  Elisabeth May 14 '13 at 3:49
add comment

I used to "Think" I really understood OOP. Well, that was until I read "Essential Actionscript 3.0" by Colin Moock. Now I "Think" I really understand OOP.

share|improve this answer
add comment

I started OOP with Delphi1. But I was always looking for the one glorious object hierarchy. The Gang of 4 Book about Software patterns open my eyes. The solid principles (and others like Law of Demeter etc.) help me to keep on track. Test driven development and Refactoring are my insurance for success.

share|improve this answer
add comment

The best way to understand Object Oriented Programming is to think in real-world-objects. Examples are Peoples, Cars, and so on.

  • Object: A Person is an Object.
  • Members: A Person has some kind of properties (state) (size, weight, name, etc.).
  • Function: A Person can do something. (speak(), eat(), sleep(), ...)

If you are unsure about class an instances:

  • A "class" is a general concept, lilke "Person".
  • A "instance" of a person is a specific Person, like "Fred Smith".

There are many instances (Fred, Wilma, Herta, Norbert, ...), but only one class (Person).

Example:

Person A = new Person(name="Fred"); // we created Fred; Fred is a Person
A.Weight += 1; // Fred got an extra pound
A.Say("Hello"); // Fred says hello
share|improve this answer
add comment

For basic OOP concepts there is a learning center designed for beginners that explains the concepts in a smooth manner.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.