CSC/ECE 517 Summer 2008/wiki3 8 jb: Difference between revisions
No edit summary |
|||
| Line 6: | Line 6: | ||
===Small Interfaces=== | ===Small Interfaces=== | ||
The principle of small interfaces says, "if any two modules communicate at all, they should exchange as little information as possible" [http://www. | The principle of small interfaces says, "if any two modules communicate at all, they should exchange as little information as possible" [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf]. Following this principle tends to lead to interfaces where native data types are preferred over classes as arguments. This serves to reduce coupling between modules, and reduce the runtime overhead required to pass parameters from caller to callee. | ||
The idea of a central data source is key to implementation of small interfaces. | The idea of a central data source is key to implementation of small interfaces. | ||
===Explicit Interfaces=== | ===Explicit Interfaces=== | ||
The principle of explicit interfaces says, " | The principle of explicit interfaces says, "If two modules communicate, this must be obvious from the text of either or both" | ||
[ | [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf]. | ||
===Uniform-access=== | ===Uniform-access=== | ||
The principle of uniform access says, "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. | The principle of uniform access says, "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" [http://en.wikipedia.org/wiki/Uniform_access_principle]. | ||
===Self-documentation=== | ===Self-documentation=== | ||
The principle of self-documentation says, "The designer of a module should strive to make all information about the module part of the module itself. | The principle of self-documentation says, "The designer of a module should strive to make all information about the module part of the module itself" [ftp://ftp.idc.ac.il/pub/courses/cs/oosc/ch1-3.ppt]. | ||
===Single-choice=== | ===Single-choice=== | ||
The principle of single-choice says, "Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. | The principle of single-choice says, "Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list" [ftp://ftp.idc.ac.il/pub/courses/cs/oosc/ch1-3.ppt]. | ||
==Links== | ==Links== | ||
Revision as of 01:41, 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
Principles
Small Interfaces
The principle of small interfaces says, "if any two modules communicate at all, they should exchange as little information as possible" [1]. Following this principle tends to lead to interfaces where native data types are preferred over classes as arguments. This serves to reduce coupling between modules, and reduce the runtime overhead required to pass parameters from caller to callee. The idea of a central data source is key to implementation of small interfaces.
Explicit Interfaces
The principle of explicit interfaces says, "If two modules communicate, this must be obvious from the text of either or both" [2].
Uniform-access
The principle of uniform access says, "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" [3].
Self-documentation
The principle of self-documentation says, "The designer of a module should strive to make all information about the module part of the module itself" [4].
Single-choice
The principle of single-choice says, "Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list" [5].
Links
Wikipedia page for Bertrand Meyer
Lesson on OO drawing on Bertrand's principles
[6]