What's the BEST way to really understand OOP? [closed]

Question

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

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

Do It

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

Answer 5

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 :)

Answer 6

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

Answer 7

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

Answer 8

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.

Answer 9

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.

Answer 10

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

Answer 11

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