Learning Object Oriented Programming

How does one go about learning ObjectOriented design and programming? Practice is clearly helpful, but some learning before practice would be helpful as well. DesignPatterns is clearly a good book, but is not really for beginners. What book or books should someone new to ObjectOrientedDesign read first?

StructureAndInterpretationOfComputerPrograms (HaroldAbelson, GeraldSussman, Julie Sussman, ISBN 0262011530 )
ObjectOrientedAnalysisAndDesign (GradyBooch, ISBN 0-8053-5340-2 )
Object Oriented Methods (Ian Graham, ISBN 0201593718 )
ObjectOrientedSoftwareConstruction (BertrandMeyer, ISBN 0136291554 )
JavaLanguage: ThinkingInJava (BruceEckel, ISBN 0136597238 )
PerlLanguage: Object Oriented Perl (DamianConway, ISBN 1884777791 )
SmalltalkLanguage: SmalltalkTheLanguageAndItsImplementation (AdeleGoldberg, David Robson, ISBN 0201113716 )
SqueakSmalltalk: A Quick Trip to Objectland (Gene Korienek, Tom Wrensch, Doug Dechow, ISBN 0201731142 )

Mine, when I finish it - don't hold your breath. It's hard to recommend a book these days. Most of the programming books from the last few years are designed to teach people enough Java to hack out e-commerce sites. I started my book in deep disgust after looking at the "programming" section in Blackwells. The worthies are there, of course, like Knuth - but the rest! I must be able to do better than the extra-wide-margin, crazy typography-around-the-page-number, three-inches-and-a-CD brigade. So I'm having a go.

Many of the OO books around that are any good are at least a few years old and tend to be quite advanced (ie, they require the reader to think while reading them - never a popular approach).

There are lots of OO related pages on Wiki scattered around. Is it possible to construct a roadmap based on what is here already? In a manner suitable for OO learners.

If the pages are categorized properly the contents can be refactored in an organized way.

We are increasingly using Java, and we have a number of programmers who we would like to retrain to use Java. Most currently use PL/SQL and COBOL. We have found that the Java syntax is not the major problem, but learning the object-oriented way of thinking. Most of these programmers were originally taught that separation of data and code is the HolyGrail. Some see the encapsulation of data and methods in an object as evil.

Of course, only a few express this extreme view. Many want to work in an object environment but just don't seem to get it. They typically produce designs with some objects that are primarily data (sometimes with getter/setter methods), and other objects that are really just containers for methods to work on the data objects.

Can anyone recommend any books/training that is specifically suited to people who have grown up with the SeparationOfDataAndCode methodology?

StructureAndInterpretationOfComputerPrograms is probably the best. If I understand the LISP way correctly, data/code distinctions are anathema.

I've found the RefactoringImprovingTheDesignOfExistingCode book really useful with former C programmers we have on our team. It's really good for showing them how to move from Data objects and objects which are just really Collections of Methods into proper self contained classes. The bits on FeatureEnvy in particular are very good at getting across what OO is all about.

-- SteveEyles

In order to wean a programmer off one programming discipline/approach and onto another, it might be useful to get going a discussion about the relative merits/pitfalls of the competing disciplines.

For instance, why is one discipline better than the other? What are/were the motivations for each? What does one accomplish that the other does not, and so on?

(Discussion moved to GateKeeper)

It would be nice if there were a book brave enough to tackle that. Bertrand Meyer allegedly made such an attempt (see below).

Can the original poster tell us what procedural languages he is using now?

Smalltalk is the language one should NOT touch when learning OO. After learning Smalltalk, you might hate C++/Java/.., whatever language you're actually using, with passion. Especially if you do learn OO. :)

When working with programmers that may be new to OO concepts, I've found that it helps to focus them on what I consider the two pillars of Object Oriented practice: DelegationPattern and SwappingClassesAtRuntime, and on what they are trying to achieve, mainly, applications that remain maintainable and adaptable as they grow in size. I think that n-tier, DesignPatterns, and the general benefits delivered by OO trace back to these two techniques.

I start programmers with basic examples of encapsulation, inheritance, and polymorphism, but I like to move very quickly to practical application. It's important to me that they DoItBecauseItMakesSense?, rather than DoItBecauseYoureSupposedTo?. Otherwise, you wind up with programmers who want to misuse design patterns, argue about why VisualBasic 6 is not Object Oriented, avoid globals because "globals are bad," create strange and wonderful inheritance hierarchies, etc. Just like we used to do, right? :)

-- JoelRosenberger

Being fairly self-taught at OOP (which probably explains my unusual view of it), I would recommend to practice/experiment in the following order:

Write single classes (no inheritance) which implement simple data storage models like linked lists, self-extending arrays, name spaces, hash tables, etc. What you are aiming to do is get a feel for how methods should be organized (i.e. how big or small a task to assign to methods). Writing data storage classes will give you a good feel for what OOP if really all about (modelling IMHO).
Once you have a rather large class, you will probably find it cumbersome to use & to maintain. It is at this point you should refactor it into a number of smaller classes, which can be done in two ways: (1) use inheritance to incrementally add more features, or (2) have classes for different aspects of the problem (such classes will then take & return other classes where needed). This will give you a feeling for how complex classes should get, and how they should probably be organized in the first place.
Now glance through the DesignPatterns book, but only use it as a source of ideas (examples) to spice-up your imagination. It should help you come-up with solutions to refactoring your monolithic class into something maintainable & flexible.
Having got some proficiency in the first two items, you can now start to try designing a class hierarchy to solve a real programming problem. You will likely have two write a number of separate class hierarchies for tackling different parts of the problem, and then combine them to solve the solution. Combining the different classes might be done in a purely old-style procedural way, although users of Java may find this harder than most.

The difficulty of designing OOP programs might seem an argument against it, but that would be too harsh. The problem is mainly down to OOP currently only having (usually single) inheritance to incrementally express larger problems, and it is this that requires expertise to avoid being misused.

You can write some pretty good OOP stuff without inheritance, and it fits well with ExtremeProgramming to only refactor single classes into a class hierarchy when it becomes obvious that this would be a good idea. You then no longer need the huge experience required to to design an OOP hierarchy correctly in the first place, but instead only need to be good at spotting (after the fact) when such hierarchy would be helpful...

-- ChrisHandley

Perhaps one should read LimitsOfHierarchies to understand some of the pitfalls and difficulties of hierarchies and identify these sticky situations when encountered.

ObjectSerialization

I think the above merits a page as there are practical considerations for ApplicationProgrammer?. I got alerted to it in an article that discussed compatibility concerns between releases of an architectural framework. In it there was caution about the fragility of the serialized object.

Subsequently I did a search on C2 and problems are talked about in bits and pieces in many places. If we have a page like the suggested name above then platform specific discussions can be linked together.

Anybody able to start a page to educate old-timers that have missed out on object technologies?

See ObjectOrientedProgramming, PeopleWhoDontGetOo, BoyThisStuffMakesMeFeelStupid

CategoryObjectOrientation