CSC/ECE 517 Summer 2008/wiki3 8 jb: Difference between revisions
| Line 9: | Line 9: | ||
<ul><li> | <ul><li> | ||
<i>"If any two modules communicate at all, they should exchange as little information as possible" </i> [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf Meyer]</li></ul> | <i>"If any two modules communicate at all, they should exchange as little information as possible" </i> [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf Meyer]</li></ul> | ||
The goal of Meyer's small interfaces principle is to reduce [http://en.wikipedia.org/wiki/Coupling_(computer_science) coupling] between classes. There are a two ways to interpret this principle, and I believe this ambiguity was intended. First, a <i>small interface</i> 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 <i>small interface</i> 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 <i>smaller</i> objects, since they would on average have less hooks to the rest of the code. | The goal of Meyer's small interfaces principle is to reduce [http://en.wikipedia.org/wiki/Coupling_(computer_science) coupling] between classes. There are a two ways to interpret this principle, and I believe this ambiguity was intended. First, a <i>small interface</i> 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 <i>small interface</i> 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 <i>smaller</i> objects, since they would on average have less hooks to the rest of the code. | ||
[[image:small_interfaces.gif|frame|center| ftp://ftp.idc.ac.il/pub/courses/cs/oosc/ch1-3.ppt ]] | [[image:small_interfaces.gif|frame|center| ftp://ftp.idc.ac.il/pub/courses/cs/oosc/ch1-3.ppt ]] | ||
This principle also has the tendency to improve [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 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. | |||
===Explicit Interfaces=== | ===Explicit Interfaces=== | ||
Revision as of 02:54, 23 July 2008
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
The goal of Meyer's small interfaces principle is to reduce coupling between classes. There are a two ways to interpret this principle, and I believe this ambiguity was intended. 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.
Explicit Interfaces
"If two modules communicate, this must be obvious from the text of either or both" Meyer
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
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
[1]