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
There are two concepts covered under the uniform-access principle. The first is closely related to Skrien's guideline, "A well-formed class has a consistent interface", and the second goes a step further and specifically talks about the notion of cached off values within a class.
The image below illustrates the concept. There are two different implementations of a bank account, A1 and A2. A1 maintains an explicit balance variable while A2 would derive the balance when queried. The uniform-access principle states that the getBalance() method of classes A1 and A2 should not look any appear to the caller.
Example
An example of the general notion of uniform notation can be taken from the lecture notes from lecture 20. The question was posed of a class having two methods,
- a method that sets the ith person’s name and
- a method that sets the ith person’s age.
It follows that the two methods should have a uniform notation for describing the two similar methods, as follows:
setName(String name, int index) setAge(int age, int index)
Self-documentation
"The designer of a module should strive to make all information about the module part of the module itself" Meyer
Discussion
The principle of self-documenting code is that the language should support constructs that enable the unification of the design document and the code. Imaging if the language that you were writing your application in supported design features of a design language such as UML. Even better, imagine if the compiler could turn your "designs" into code. This is the vision for self-documenting code. The concept of literate programming put forth by Donald Knuth is another effort towards self-documenting code.
Meyer's Eiffel language supports notations embedded in the language that support this principle [2]. Support for self-documentation is limited in languages other than Eiffel. The closest thing that major O-O languages such as Java and C++ have are systems such as Javadoc and Doxygen. These systems implement parsers which extract comments encoded with formatting tags to generate rich HTML documentation straight from the code.
Example
Skrien, 91
/**
* The time class represents a moment of time.
*
* @author John Doe
*/
class Time {
public:
/**
* Constructor that sets the time to a given value.
* @param timemillis is a number of milliseconds passed since Jan 1. 1970
*/
Time(int timemillis) {
}
/**
* Get the current time.
* @return A time object set to the current time.
*/
static Time now() {
}
};
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
[3]
Interview with Meyer discussing Design by Contract