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.

(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.

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.