| Classes are currently the best way for programmers to achieve modularity. But modularity is a big topic, and it extends beyond classes. Over the past several decades, software development has advanced in large part by increasing the granularity of the aggregations that we have to work with. The first aggregation we had was the statement, which at the time seemed like a big step up from machine instructions. Then came subroutines, and later came classes. Cross-Reference For more on the distinction between classes and packages, see "Levels of Design" in Section 5.2.
It's evident that we could better support the goals of abstraction and encapsulation if we had good tools for aggregating groups of objects. Ada supported the notion of packages more than a decade ago, and Java supports packages today. If you're programming in a language that doesn't support packages directly, you can create your own poor-programmer's version of a package and enforce it through programming standards that include the following: Naming conventions that differentiate which classes are public and which are for the package's private use Naming conventions, code-organization conventions (project structure), or both that identify which package each class belongs to Rules that define which packages are allowed to use which other packages, including whether the usage can be inheritance, containment, or both
These workarounds are good examples of the distinction between programming in a language vs. programming into a language. For more on this distinction, see Section 34.4, "Program into Your Language, Not in It." cc2e.com/0672 Cross-Reference This is a checklist of considerations about the quality of the class. For a list of the steps used to build a class, see the checklist "The Pseudocode Programming Process" in Chapter 9, page 233.
CHECKLIST: Class Quality Abstract Data Types Abstraction Does the class have a central purpose? Is the class well named, and does its name describe its central purpose? Does the class's interface present a consistent abstraction? Does the class's interface make obvious how you should use the class? Is the class's interface abstract enough that you don't have to think about how its services are implemented? Can you treat the class as a black box? Are the class's services complete enough that other classes don't have to meddle with its internal data? Has unrelated information been moved out of the class? Have you thought about subdividing the class into component classes, and have you subdivided it as much as you can? Are you preserving the integrity of the class's interface as you modify the class?
Encapsulation Does the class minimize accessibility to its members? Does the class avoid exposing member data? Does the class hide its implementation details from other classes as much as the programming language permits? Does the class avoid making assumptions about its users, including its derived classes? Is the class independent of other classes? Is it loosely coupled?
Inheritance Is inheritance used only to model "is a" relationships that is, do derived classes adhere to the Liskov Substitution Principle? Does the class documentation describe the inheritance strategy? Do derived classes avoid "overriding" non-overridable routines? Are common interfaces, data, and behavior as high as possible in the inheritance tree? Are inheritance trees fairly shallow? Are all data members in the base class private rather than protected?
Other Implementation Issues Does the class contain about seven data members or fewer? Does the class minimize direct and indirect routine calls to other classes? Does the class collaborate with other classes only to the extent absolutely necessary? Is all member data initialized in the constructor? Is the class designed to be used as deep copies rather than shallow copies unless there's a measured reason to create shallow copies?
Language-Specific Issues |
|
