IceDane

While reading books on general C++ programming is all well and good, not many of them seem to cover OO design.
By OO design, I mean whatever it is that will equip me with the skills and knowledge to identify which design patterns should be used in which scenarios.

Are there a special book that you guys would recommend on this subject? Because I find myself wondering which design patterns I should be using.

Any resource would be greatly appreciated.

__________________
"What's up, Doc?"
"'Up' is a relative concept. It has no intrinsic value."

Dino

HEAD FIRST has one on OO concepts.

Amazon.com: Head First Object-Oriented Analysis and Design (9780596008673): Brett D. McLaughlin, Gary Pollice, Dave West: Books

__________________
Mac and Windows cross platform programmer. Ruby lover.

Bubba

Amazon.com: Design Patterns: Elements of Reusable Object-Oriented Software (0785342633610): Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides: Books

Might I also recommend a book on what can go wrong with using OO patterns:
http://www.amazon.com/AntiPatterns-R...0044768&sr=8-1

__________________
I remember when The Weather Channel talked about weather, MTV played music videos, and the History Channel talked about history instead of conspiracy theories.

Sebastiani

The first rule of OO desig is to not use OO design - write code as if the member variables were C global variables (just be sure to always be encapsulated, avoid static variables, etc). Once everything is working properly then finish implementing the user interface of the class, run test cases, etc.

As far as patterns go, remember to include mundane operations as well (anything that can be generalised), and make them free-form functions wherever possible. Focus on templates, and always try to abstract the problem out, eventually you'll build up a toolbox of reusable components that can be connected interchangeably.

Finally, remember that OO isn't only about "everything as an object" - functional programming is also very important. The main thing, though, is to just use "common sense", and to avoid complicated solutions where more simple simple ones are sufficient.

Bubba

One of our members used to have the quote that class design should not be like a swiss army knife. I think the quote had more to it but the idea is classes should focus on one important aspect of the system and they should be the best at what they do. When you try to make one class do to much or support everything on the moon it quickly becomes a nightmare.

Limit your inheritance to one concrete derivation if possible and often aggregation or composition will work. I see inheritance used far too often which usually results in a very complicated class hierharchy that is definitely object-oriented but almost impossible to use.

__________________
I remember when The Weather Channel talked about weather, MTV played music videos, and the History Channel talked about history instead of conspiracy theories.