Besides the general, "What is OO?" question, I want to understand how one transitions from a procedural-based programmer to someone who gets OO.
I'm anticipating the winning answer would contain thoughts on SOLID, as well as some practices/drills for increasing our skills in design and development that fully leverages OO. Books/classes/mentors also acceptable.
I don't know if I would like to label this as the "best" resource, but one that I found to be very helpful when I was getting the grasps of object-oriented fundamentals was Head First : Java (Kathy Sierra, Bert Bates). I tend to be a very visual learner and this book really reinforced a lot of fundamentals that were a little fuzzy to me in the academic setting. In my case, I had a great grasp of procedural logic and tried to apply these principals to object-oriented design, which defeats the purpose of OO completely. The pacing & reinforcement of this book really helped me to get a better handle on a lot of the abstract & organizational logic.
I learned OO from lots of really boring technical manuals I was forced to read in the 90's by teachers and managers but I didn't understand it until I started to code OO in python.
My C++ improved tenfold after I forgot all the conflicting terms and mumbo jumbo and started doing.
I'm sure the books have improved but may I suggest if you are having difficulty using any of the resources suggested building a few simple toy apps in a language that makes OO easy.
Beginner advice:
Dog.bark()
Dog.eat( cat )
Dog.eat( dog )
Dog.name = 'Puppy'
Dog.color = 'red'
I guess that's one way you can "think in OO", sorry for the lame advice.
I've read Code Complete, Head First: Java (and the JSP Servlets one too) and several other OO books. By far, the best one is:
Beginning Java Objects: From Concepts To Code, Second Edition by Jacquie Barker
It may be because I read it after the Head First ones, but when I read this book OOP really "clicked" for me. Specifically the first six chapters. I read them one Saturday and went back to work on Monday and by Wednesday had completely re factored a huge portion of my OO architecture design (for a project I was getting ready to begin coding on).
Now that I think about it, I never picked the book up again to read the rest of it, but those first 250 pages (or so) were sort of "life changing" as far as the way I thought about Objects and helping me to understand OOP...
@ cmcculloh : I second the nod towards Code Complete...Steve McConnell has taught me quite a few lessons that are reiterated to me over the head every day at work.
Some more conceptual advice:
"has a": A dog has a tail; therefore the Dog class should have a member "tail"
"is a": A poodle is a dog; therefore Poodle should either be an instance or derived class of Dog
Thinking this way really sped up my ability to design object oriented structures. Otherwise, starting out it's easy to get twisted up and start adding members to classes that should actually just be instances, or vice versa.
I've recently picked-up a copy of the new book Dojo The Definitive Guide from O'Reilly. Most of the concepts I've encountered so far (I haven't completed reading the book yet) are clearly explained. Some previous experience with web markup languages such as HTML and familiarity JavaScript in particular might be helpful, if not required, to understand even the early concepts introduced.
I think one of the best ways is just to dive into it. Create a test project with a few classes and methods and just play around with them and see how they interact to get the basics down.
I think the best starting point is a book that I read called Object Oriented Analysis and Design by Grady Booch. Its got one of the best treatments of the subject I have ever seen. It is not dependent on any particular programming language.
A must read for anyone who wants to write large applications. It deals with how to handle complexity through various OO concepts (primarily abstraction).
http://www.amazon.com/Object-Oriented-Analysis-Applications-Benjamin-Engineering/dp/0805353402
Even though Code Complete is an excellent book, it's not about thinking in OO terms. The best book on this topic is Craig Larman's Applying UML & Patterns. I've already read it three times, often come back at random pages and always learn something new.
After reading it I'd suggest Design Patterns Explained, by Alan Shalloway, which is a perfect introductory book to this important topic. After going through those books, you might be ready to face Design Patterns, the seminal book by the famous Gang of Four, which is a bit hard core to understand but the most important one on the topic.
I would surely recommend Head First OOA&D. The book is well written, has numerous examples by which each OO concept and its practical use in that particular example/case-study are explained rather well.
Do give it a try as the first book. It will get you thinking in OO and its a very easy read.
saint_groceon's beginner advice although correct, can lead to trouble:
Objects are not just a collection of attributes and behaviors. If that was the case, dogs and cats would be indistinguishable from each other, as they both have eyes, mouths and legs, and they both eat, sleep and play. In fact, this kind of "object" is almost no different than a C struct.
Furthermore, the type of thinking described in saint_groceon's post also leads to other problems: If your "Duck" class has a "quack" method, what happens when you need to implement a rubber duck that does not quack? (you may recognize this example from Head First Design Patterns)
I agree with the fact that objects are usually nouns from the domain's language. However an object is more than that: an object is anything capable of providing a limited set of useful services. And then, with these objects "we decompose the complex world around, and assemble those objects in various ways so that they can perform useful tasks on our behalf" (David West).
West nails the definition of an object; the most important characteristic of an object is it's ability to be composed with other objects to create useful things, much like all of our body parts (properly assembled) make us useful creatures. So, in some respect, everything is an object!
Edit:
I realize that I said little about How To Think OO, and a lot more about what OO is not. I apologize for this, but I'm no OO master, and I'm barely at the stage where I have a feeling what OO IS NOT... I'm not at the point where I can instruct on OO.
This post was mostly an exercise to help me gather my thoughts about what I've learned so far. I hope you'll find it useful nonetheless.
I always enjoyed The Object Oriented Thought Process by Matt Weisfeld. Short, sweet and simple. I'll usually re-read it every one to two years.
For OO I really liked David West's Object Thinking book. It was more a philosophy book than a technical book. He really pushed the idea of objects being defined by their behavior not by their data.
Keith
Bruce Eckel's Thinking In C++ is C++ centric, but has a lot of information about thinking in an object oriented way. He delves into composition, has-a and is-a relationships, polymorphism, inheritance, all those goodies. I really like his books.
Head First Java is a fantastic book, but as Hazar says, just dive in - at least you'll learn from your mistakes (which will be numerous). What is particularly worthwhile is learning a language that will only allow OOP - that way you can't rely on your procedural mindset.
The real world is not OO, most problem domains are not OO, so first I think you should consider whether this is even a worthwhile pursuit.
I endorse everything @Esteban said. I suggest you read the very good Domain Driven Design book, by Eric Evans. It has a short version avaiable for free online. The beggining of the book shows a step by step construction of a domain model, built from a conversation with the client. Other interesting discussion is how to avoid Anemic Domain Models, an overused procedural style in OO languages.
@DrPizza, I agree the exists situations where you should stick with procedural languages, but most business problem domains are easier to think in a OO fashion. Humans thinks naturally in an ontological way, and OO programming is much closer to that then procedural.
I agree the exists situations where you should stick with procedural languages, but most business problem domains are easier to think in a OO fashion. Humans thinks naturally in an ontological way, and OO programming is much closer to that then procedural.
There is no evidence that humans think in an OO way, and in actual fact, there is some evidence that OO is no more suitable to human thinking than any other design (ref: "On the Usability of OO Representations", Communications of the ACM Oct. 2000.). Key quotation:
Object-oriented representations do not appear to be universally more usable or less usable.
It is not enough to simply adopt OO methods and require developers to use such methods, because that might have a negative impact on developer productivity, as well as the quality of systems developed.
I really have strong doubts about whether what you say is true; that "most business problem domains are easier to think of in an OO fashion". I think what little research there is in this area does not support the claim.
Other research into "how humans think" (vis-a-vis programming paradigms) suggests that an event-driven model is in many cases the most natural, which is neither OO nor procedural.
You don't necessarily need to learn to code in it, but reading about Smalltalk and how its primary language construct is a message really drove home OO for me. Before, I viewed classes, like most people, as self-contained global variables with methods, instead of hidden data with message handlers.
The Head First series of books contain very good material:
Head First Object-Oriented Analysis and Design
Head First Software Development
Also, Object Thinking
Highly Recommended.
Personally I enjoyed Object Thinking and this is the book that really made OO "click" for me. Once I read this I finally understood why OO is great, but also that good OO was harder than I used to think.
I haven't read all of the books people have mentioned, but I too can recommend David West's Object thinking. It's very light on code, which I think drives the point home.
Other than that, the real trick to learning how to apply OO is to think about your objects more as abstractions and behaviors rather than the data/properties that an object might have.
Another trick to applying OO is to understand that OO is as much, if not more, about modeling constructs rather than physical real world objects. Example: in an accounting system you may have payment method objects and/or discount algorithm objects. OO systems tend to be filled with objects that do not model something physical.
You definitely need to dive in and create a few classes and use them. It is sort of a catch 22. You can't understand what you read until you've done it a few times and you can't do it a few times until you read something.
So pick one of the recommended books and do some implementing of a few classes of your own while you are reading the book. I personally liked the Thinking in ... books from Bruce Eckel.
My two most appreciated teachers are:
"Uncle Bob" Robert C. Martin:
Watch out his excelent OO-Papers on (I learned a lot by reading them!):
ObjectMentor and also his book that combines OO-Bestpractices, Agile development and Design Pattern.
and
Arthur J. Riel with his excelent book about design heuristics.
The first thing you must realize is that the OO paradigm is really easy. Don't be intimidated by it.
The important relationships in OO are (name,uml,description,example):
Has a
<>- (aggregation)
<*>- (composition)
Class declares an object in it's declaration, class determines the lifetime of the object.
Composition: lifetime of member object depends on object that has it.
Aggregation: lifetime of member object depends on "new" and "deletion" from the object that has it.
Example: Dog has a head.
Knows a
-> (solid line)
Class declares an object in it's declaration, class doesn't determine the lifetime of the object. The object will be passed to this class via constructor of a set method (by use of pointer or reference).
Dog knows it's mother.
Uses a
--> (dashed line)
Class will create an object temporarily and either pass it off to a client or end it's lifetime. It could also be an object passed to the class that it uses temporarily in a function. No member variable to save the object in the class.
Dog uses a bone to clean it's teeth.
Is a
-|> (solid line with triangle)
--|> (dashed line with triangle, implements)
Class derives another class. That is, the class can be viewed as the class it derives from. The derived class contains each function and member variable of the class it derived. This is the key to polymorphism. The "Implements" relationship simply means that the class derives a special class which is called an interface. An interface contains only functions (or methods) that need to be implemented by the class deriving it. The interface has no definition for the function, so the derived must provide it.
Dog is a mammal.
Polymorphism is another important term used. It basically means doing something with a derived class by interacting with it being viewed as it's base class (the class it derived). For example, if you had a dog, a cat and a person and you wanted them all to talk..you could look at them as mammals and call a function Talk(). The dog might use the function Bark() in the Talk() function, the cat might use the function Meow(), and the person might use the Speak("Why am I grouped with cat's and dog's?").
The SOLID principles are rules to follow concerning these relationships.
OO Design patterns are reoccurring patterns that solve a certain problem. It's basically ways to design your code to follow the SOLID principles.
Other than that, learn a language that supports OO and dabble in it. Try out these relationships first, try to draw out your design in UML, and write it! Then try to understand some of the design patterns and how they relate to the SOLID principles. If you can do that, you're basically thinking like an OO designer/developer.