> Rely on the old mantra: If you think of <i>it</i> as a separate idea or object, represent it directly in the program; model real-world objects, and abstractions directly in code.<p>I think this is terrible advice. Thinking of object-oriented programming as "world modeling" leads to complicated designs that came from someone's pointless ontological analysis rather than practical considerations of what will make the best, easiest-to-understand program.<p>A simple example of this is the OO conundrum: should square derive from rectangle? After all a square is-a rectangle. If we're world-modeling, then the inheritance relationship is a beautiful and consistent expression of this platonic idea that a square is a special kind of rectangle.<p>But in practice, this inheritance relationship has lots of problems.
<a href="http://stackoverflow.com/questions/1030521/is-deriving-square-from-rectangle-a-violation-of-liskovs-substitution-principle" rel="nofollow">http://stackoverflow.com/questions/1030521/is-deriving-squar...</a><p>And what was it really buying you to begin with? Pretty much nothing.
><i>However, to minimize confusion, I'll keep referring to the upcoming C++ standard with the feature set defined here as C++0x. Think of 'x' as hexadecimal (most likely 'B', i.e. C++11).</i><p>Just have to point this out: <i>this</i> C++ goes to <i>eleven</i>.<p>I should look into C++0x some time; I've been hearing good things, but I've never touched it.
The hamming and hawing on this one says everything one needs to know about C++0x:<p><a href="http://www2.research.att.com/~bs/C++0xFAQ.html#learn" rel="nofollow">http://www2.research.att.com/~bs/C++0xFAQ.html#learn</a>