How would you recommend I go about learning about Object Oriented Design/Programming?
I prefer to learn based on books first (it's likely a bias of mine based on the assumption that books are edited for quality, which "random" websites would not - discuss in question comments if you wish), so I'm really looking for a couple great beginner books on the topic. If there is a definitive website that covers this, I'd be open to that too if it's known to be good quality.
It's big, it's dry and it's a slog, but yes: Design Patterns: Elements of Reusable Object-Oriented Software. At least read the case study over the first 80 pages.
Ultimately it's down to experience, specifically of real-life systems, big or small. It wasn't until then that it became second nature.
For 'new-style-oo' (less focus on reuse through inheritance) I'd have to say Agile Software development by Robert Martin. It lists all the basics like open/closed principle, reduce coupling/ increase cohesion, liskov substitution principle, IoC and so on. Design patters (especially the first chapters) is a good read after that, it uses the same principles but explains them less thoroughly.
If you're more into .Net there's a C# focused version of this book too.
I may get booed for this here, but I actually liked Head First Java. It is easy to read, and the authors are experienced teachers of newbies, so a lot of the questions you get when you read it are often immediately answered. Though if you are an experienced programmer you will probably find it too basic, and some people find the cartoony style offputting.
If you come from a c/c++ background, playing around with a bit purer OO language than Java is a good idea too, where even integers are objects with methods on them, and everything is "pass message to object". Say, Ruby, Python, Smalltalk. You start "getting" OO more completely then.
The one I found most useful (and with the added bonus of a development process as framework) was Craig Larman's "Applying UML and Patterns". IMHO it's embedded in a pragmatic reality which is refreshing.
Books are cool, but they will really only take you up to a certain point - at which time you have to go do stuff.
To really grok it, there is no substitute for doing stuff.
A lot of people will say Design Patterns, which is a good choice. But I would say Refactoring is an even better choice.
Design Patterns gives you a lot of good knowledge and advice if you already know OOP, it's definitely a required fundamental for any serious developer. But Refactoring gives you not just a toolkit with some vague instructions and advice on when and how to use it but it gives you concrete advice on how, when, why, and where to use very targeted OO techniques. Also, even more than Design Patterns, Refactoring provides the mental models and the vocabulary to discuss and tackle OO design problems. In the end I think that ends up being more important.
Design Patterns are for building from the ground up. That's not the norm, the norm is working with existing code (likely that others have contributed to): adding features; fixing defects; and improving design (refactoring). Refactoring targets the norm, Design Patterns targets the exception. Design Patterns is sexier, but Refactoring is more useful more often.
Let me put it this way, if I was asked whether I'd rather have a coworker who had read and thoroughly understood Design Patterns or one who'd thoroughly understood Refactoring, I'd choose the latter in a heart beat.
Object oriented software construction from Bertrand Meyer is good if you can bear the writings about the superiority of Eiffel against whatever.
Then there is Object Oriented programming in Common Lisp which shows a complete different approach.
Howerver I can not name any book which treats object-orientation negativly. I do not feel this is "appropriate". Wirth books have read "data structures and algorithms" and well OO is more or less about the first part (if you subtract the "blocks" objects e.g in Smalltalk, Ruby, Io etc), the algorithm page is often under represented in any OO book.
You will learn about how to derive objects and the like so in facts you see mostly guidelines for handling Data structures, algorithms often get tucked upon. In this way (pseudo code)
class ACTION feature do_something....
endclass
class FOO_ACTION inherit ACTION redefine do_something ...
endclass
class BAR_ACTION inherit ACTION... endclass
This is a "trap" in which quite a few class-libraries step in...
However my recommodation would be looking at langauges beeing "pure-OO" as e.g Smalltalk, if you look at hybrid languages you've to see the non OO-stuff tagged on it. C++ is an especially prominent example for the later. You'll find thousans of books about C++, but you can use C++ to write C with a bit more comfort....
Regards Friedrich
try uncle bob's http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445
"Fundamentals of Object-Oriented Design in UML" helped me quite a bit.
"Object-Oriented Analysis and Design with Applications" by Grady Bootch is one of the best books for your purpose.
It isn't attached to any concrete language and it is one of the best books about OOP/OOD for beginners.
There's a lot of books suggested here, my suggestion would be to temper any book you read (even if it's a Fowler book) with a grain of salt -- look around the internet and your local community meetings/etc for discussions on the best practices you'll read about in books like Refactoring. Real understanding comes from knowing when to (and when not to) apply patterns and adhere to practices, not so much knowing how they work.
This (+ practice) is the only way you'll go from a superficial understanding of OOP/OOD to "grokking" what it's really about.