6.3 Design standards

Design standards

Coding standards are concerned with a very small-scale standard. Nonetheless, object-oriented systems also require some larger-scale standards. Techniques like polymorphism or components make sense only if they match the general design.

Very often I hear people comparing object-oriented technology to electronic parts. As a former electronics student (I chickened out and majored in business instead), I can agree with that. However, the analogy of electronic parts doesn't work well, either, unless they match the overall design. Have you ever tried to push a Pentium II processor in a 68000 socket? Not a good example? Then try using a simple transistor with something that provides the wrong voltage. Get the idea?

Ideas like components and code reuse are wonderful, but no matter how generic and self-contained a class is, you won't be able to use it unless you somehow manage to make it match your standards. Very often, you can accomplish this using wrapper classes. However, this works only if the component has been designed properly and follows a well-defined interface.

Unfortunately, design standards are not as straightforward as coding standards. There are no clear rules to follow or standards you could simply reuse. You'll have to work out your own standards. These standards should be concerned with naming classes and methods, as well as behavior ownership issues and so on.

Whenever you create objects that do similar things, make sure you give the same name to the methods that perform the same functions. Don't call one of the methods Execute(), another one Build() and a third one Do(). Pick one of them it doesn't matter which one. When you create different classes that play together, make sure you keep some consistency with behavior ownership. Let's say you have an InvoiceLogic object and an InvoiceInterface object. Decide up front which one of these objects should be responsible for saving the invoice. If you create a CustomerLogic and a CustomerInterface later on, stick to this decision. It doesn't matter which one of these objects gets the behavior, as long as the Logic or the Interface gets the behavior for any item.

You also have to find a common notation for the design phase. I recommend using the UML notation. However, I won't go into the details here because I devoted Section 3 of this book to object design and UML.