Possible Duplicate:
What books or resources would you recommend to learn practical OO design and development concepts?

I have been mostly a C programmer so far in my career with knowledge of C++. I rely on C++ mostly for the convenience STL provides and I hardly ever focus on good design practices. As I have started to look for a new job position, this bad habit of mine has come back to haunt me. During the interviews, I have been asked to design a problem (like chess, or some other scenario) using OOP and I doing really badly at that (I came to know this through feedback from one interview).

I tried to google stuff and came up with so many opinions and related books that I don't know where to begin. I need a good through introduction to OOP design with which I can learn practical design, not just theory.

Can you point me to any book which meets my requirements? I prefer C++, but any other language is fine as long as I can pick-up good practices.

Also, I know that books can only go so far. I would also appreciate any good practice project ideas that helped you learn and improve your OOP concepts.

  • 1
    I think it might be helpful if you included some information on how you're currently trying to solve these problems. It's hard to know what you already understand without that.
    – KChaloux
    Oct 30, 2012 at 18:35
  • @KChaloux I am familiar with the mechanisms of classes, inheritance, polymorphism because of a c++ class I took in univ. But I can't seem to use these concepts to form a good design. Most recent use case(Interview) Ex: Design chess using oop. My answer sucked as per the interviewer. Oct 30, 2012 at 18:43
  • Is there a specific aspect you have trouble integrating? Generally when approaching an OO design, I try to look at things that can be modeled, and those become classes. In this case, you have a ChessPiece that has a position on the board, and is capable of moving, and specific pieces like Knight or Rook that inherit from ChessPiece to restrict what kinds of movements they can act upon.
    – KChaloux
    Oct 30, 2012 at 18:45
  • That part I got right. The problem was with integrating rules every piece should obey along the class hierarchy. Ex: ChessBoard rule: Not all Pieces can move during a check. ChessPiece rule: Black piece cannot move into a occupied square of same color. ChessKnight Rule: How knight moves.etc. All these rules should be checked during a move and I couldn't come up with a good way to integrate these rules across different classes. Oct 30, 2012 at 18:52
  • I suppose the way to go here would be to define a Rule class that has a method such as CheckProhibitedMove or some such, which would check to see if a potential move matches one that the given algorithm says is prohibited. So movement rules would be a member of ChessPiece, likely a collection assuming multiple rules can apply to a piece, and each would be checked before a movement is carried out. I think what they're looking for here is an understanding of both inheritance (which you seem to have down) and composition (which you might be a bit shaky on).
    – KChaloux
    Oct 30, 2012 at 19:06

6 Answers 6


As for training, I suggest going to http://www.cleancoders.com/ and watching those. They cover very important ideas.

Once you have watched the videos, take a look at Head First Design Patterns. That walks you through a number of problems and solutions.

I don't have specific project suggestions, but I would advise you to try whatever project in a strictly object oriented language such as Java. C++ let's you cheat too easily, and maybe without even knowing you are doing so.

  • 1
    Mr. Ben!! Welcome to SO. btw, you look angry in that picture
    – DXM
    Oct 30, 2012 at 22:16
  • I read one post from Uncle Bob, and if I may base my opinion of him based on that, I'd say he's full of shit. (Some article about refactoring some code into methods that basically did one instruction each. The so-called power of abstraction taken to its dire limits.) Oct 30, 2012 at 22:58

(IMO) There are not great books about software design. Many of the patterns books (I prefer the original, but have heard good things about some others) are pretty good to get the terminology and firm up concepts, but they should be used only after some practice. Without the practice first, programmers tend to over-apply design patterns or misunderstand what problems the patterns prevent.

As for practice problems, I recommend something you've already done for a start. Then you understand the domain and what it's supposed to do and can focus on design alone. Mostly though you just need to iterate. Design a program, implement it, see how it works (and doesn't). Make a new design with lessons learned for a new problem, repeat.

Program design is one of those things that ends up being more craft than science. Keep at it and you'll get progressively better.


The 'Head First Design Patterns' book mentioned in the Ben's answer is excellent. It really brings the ideas from the original 'Gang of Four' Design Patterns Book to life.

As Telastyn says in the answer, understanding to domain is critical and this will really help inform your object model. For this I really recommend Eric Evans' Domain Driven Design. It also has a great bibliography of books on OO.

Finally, your approach to testing will inform the way you design your software and what OO patterns you use.

I didn't really 'get' Factory Pattern until I had to write a unit test for some legacy code which in its constructor created one of its dependencies.

This made it very hard to test and drove me to refactor the code to have the dependency created by a Factory which when the tests were being run could be set up to return a mock object.


A great book on the subject is Object Oriented Design Heuristics. The book has over 60 heuristics in it which are language independent. In addition to the theory the book has a 122 page appendix of C++ examples. I can't recommend this book enough, it is an excellent introduction.

It's a bit more difficult of a read, but Applying UML And Patterns is also a great introduction. This book is huge and is not a quick read, but it uses two case studies to introduce the material (the monopoly game and a point of sale system).

These two books (and Refactoring) are 3 of the biggest influences in my programming career. You won't be disappointed.

  • +1 for "Object Oriented Design Heuristics". A completely under-appreciated book. Nov 3, 2012 at 6:44

I think Uncle Bob's Agile Principles, Patterns, and Practices would be a really good book for you. The book uses C# for many examples but think of those examples as pseudo-code rather than production C#. Everything that book teaches can easily be applied to just about any OO language and the level of material will probably be perfect for you.

While you are new and learning, I would strongly advise to stay away from "design patterns" books. Too many people pick those up, learn few patterns and start slapping them all over the place. As Uncle Bob points out in the above book, you should code into a pattern when you see one developing, rather than starting with the goal of building a specific pattern in the first place. However, you need good OOP sense before you can make design decision that would lead you to a pattern.

As far as material outside of the books, I would say learn the SOLID, KISS and DRY principles. And when I say "learn", I don't mean read about them and think you understand them. I mean, when you code you live and breath those principles. Every time you add another function or another variable keep asking yourself:

  • am I duplicating existing code?
  • Is my function/class doing too many things?
  • Can what I just wrote be done simpler?
  • ....

As @worldofchris mentioned (+1 to that answer), I would also recommend learning TDD while you are learning OO. The two go hand-in-hand and well-designed code, will lend itself to be easily testable. Conversely, if your code is already testable, it's quality will tend to be higher in relation to code that has no unit test coverage.

  • Clean Code

  • Pragmatic Programmer

  • Working with Legacy Code

The majority of books will make you feel happy. That won't get you a job.

Start by reading few chapters of Pragmatic Programmer and then move onto Clean Code. Review your old code as you read the books and start refactoring.

Reading books won't give you experience, but making your code "clean" will. It's up to you to decide when to draw the line regarding quality of your code.

Reason why I recommend these books is because guys who wrote them have been working in this industry for decades, and they have a very good idea of what works and what doesn't.

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