Most of you advanced software developers know these things already. But I once heard it said that "EE types see C++ as 'C with classes,'" while "CS types" invent unmaintainable designs with multiple layers of abstraction and esoteric tricks.
Some software developers might be tempted to take a jab at EEs trying to be software engineers, but in the industries in which I work, blurring of the demarcation between hardware engineer and software engineer is a fact of life. So I'm collecting a few one-liners here in hopes of eventually finding a coherent way of transforming some developers' perceptions of OOD as merely a way to containerize code and data into a vision for building on the accomplishments of their predecessors, their peers, and their tool suppliers.
A design using many small, focused classes promotes reuse much better than a few large classes that try to do too much.
"Subclass and extend" promotes maintainability better than "copy and modify."
Interfaces, whether you use the explicit mechanisms supported by Java and C# or an informal mechanism under C++, are immensely useful for making objects serve multiple roles in an application.
When choosing names for Java packages or C++/C# namespaces, there are certain ones you should avoid, because it's too tempting to use them as catch-alls. Even Sun made this mistake in the Java class library. Always choose package or namespace names that are more specific and descriptive than these:
utility, utilities, or any abbreviation thereof
miscellaneous or any abbreviation thereof
etc