CSC/ECE 517 Summer 2008/wiki3 8 jb
This wiki will explore some of Bertrand Meyer's contribution to OO design, including the principles of small interfaces, explicit interfaces, uniform-access, self-documentation, and single-choice. We intend to show good examples of each principle, discuss their support in languages other than Eiffel, and discuss whether it is difficult to follow these principles in certain OO languages.
Background
Bertrand Meyer is a professor of Computer Science at ETH Zurich, and is the creator of the Eiffel programming language. Meyer authored a book, titled Object-Oriented Software Construction in which he presented five principles of good Object-oriented design.
Meyer's Five Principles
Small Interfaces
- "If any two modules communicate at all, they should exchange as little information as possible" Meyer
Discussion
The goal of Meyer's small interfaces principle is to reduce coupling between classes. There are a two ways to interpret this principle, First, a small interface could mean that it has a small parameter list. Minimizing the number of parameters, regardless of the parameter's data type would have the tendency to reduce coupling. Second, a small interface could refer to the size of the individual parameters being minimized. In this case, you would also achieve a reduction in coupling by passing around smaller objects, since they would on average have less hooks to the rest of the code.
This principle also has the tendency to improve cohesion, and could be seen as related to Skrien's principle of "A method should do one thing only and do it well". [Skrein, 87]. Methods taking a high number of parameters, on average, are probably doing several tasks and requiring several inputs, and would not be cohesive. Another observation that could be made about methods with too many parameters, is that the parameters are somehow related and should be grouped together in a separate class. Support for the small interface principle is provided in all of the major O-O languages, notably Java and C++.
Example
test
Explicit Interfaces
- "If two modules communicate, this must be obvious from the text of either or both" Meyer
Discussion
The idea behind explicit interfaces is that if someone makes a change to a class, they would want a way to know about all other classes that could be affected [1]. The figure below illustrates the concept with an example of the problem that explicit interfaces attempt to solve. Consider two classes A and B, which communicate through a common data item X. A modifies x and B accesses x. How should the maintainer of A be made aware of the downstream implications of changing the way in which x is calculated, or changing the allowable range of values over x?
The principle of explicit interfaces is closely related to the concept of Design by contract. Design by contract focuses on specifying preconditions, postconditions, and class invariants, and supporting these assertions explicitly within the language.
Example
Uniform-access
- "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation" Meyer
Discussion
Example
Self-documentation
"The designer of a module should strive to make all information about the module part of the module itself" Meyer
Single-choice
"Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list"
Meyer
Links
Wikipedia page for Bertrand Meyer
Lesson on OO drawing on Bertrand's principles
[2]
Interview with Meyer discussing Design by Contract