| Software design principles underlie the guidelines presented in this book. These principles embrace some common underlying themes including abstraction and separation of concerns. Some of these principles are directly reflected in the guidelines and others are implicit. Here are some generally accepted principles that are embodied in the guidelines: -
Well-Defined Interfaces
-
A well-defined interface is like a great user's manual. The user knows exactly how to perform desired operations and what the result will be. An interface includes the operations that it performs for the user, as well as any access control that designates which users can perform an operation. The Liskov Substitution Principle [*] denotes that any implementation of an interface should respect the definition of that interface. [*] Barbara Liskov, Data Abstraction and Hierarchy , SIGPLAN Notices, 23,5 (May, 1988). See http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple. -
Decomposition and Modularity
-
Systems should be decomposed into modular components. Components should be designed to be reusable, if possible. -
Prioritized Requirements
-
All requirements cannot be implemented at the same time. Requirements need to be prioritized by the client to determine what should be implemented first. -
Abstraction
-
Abstraction deals with the essential characteristics of a system and the components of the system. Data and control are represented by abstract descriptions, not by specific implementations . The concentration is on the what and not the how . Implementation details, such as the language in which a system will be written, or the platform on which it runs, are not considered . Thus, abstractions are more stable than implementations. -
Information Hiding
-
Information hiding is a means for achieving abstraction. Well-defined interfaces expose functionality, but not implementation. Algorithms, I/O formats, and data representation are not exposed outside the interface. -
Extensibility
-
The Open /Closed Principle , as stated by Bertrand Meyer ( Object-Oriented Software Construction , [Prentice Hall, 2000]), says that components should be open so that they are available for extension, yet closed so that they are usable by other components. This principle is typically demonstrated with inheritance. A base class is closed, but it is open to extension by inheritance. -
Hierarchy
-
There are levels in systems, such as inheritance hierarchies or layers of abstraction. -
Separation of Concerns
-
Modules are split up into components that have separate orthogonal concerns. -
Packaging
-
Components that change together should be packaged together. |
