Some Object-Oriented Design Maxims

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.

  1. A design using many small, focused classes promotes reuse much better than a few large classes that try to do too much.

  2. "Subclass and extend" promotes maintainability better than "copy and modify."

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

  4. 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:

Chuck Taylor -- (Copyright) -- (Contact)