CSC/ECE 517 Fall 2007/wiki3 7 cl: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 13: Line 13:


====Example of Principle of Small Interfaces ====
====Example of Principle of Small Interfaces ====
An ATM Example uses a Message class to encapsulate
details of a Message from a Transaction to the bank. This is used as a
parameter to the sendMessage() method of NetworkToBank - in place
of a long list of specific parameters. This means that only the sending
Transaction and receiving bank need to be aware of the details of the
structure of a message - not the intermediate class(es) comprising the
network.


===Principle of Explicit Interfaces ===
===Principle of Explicit Interfaces ===
Line 55: Line 62:
The single-choice principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.
The single-choice principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.


====Example of Single-choice Principle ====
====Examples of Single-choice Principle ====
Example 1 - Editor: set of commands (insert, delete etc.)
Example 2 - Graphics system: set of figure types (rectangle, circle etc.)
Example 3 - Compiler: set of language constructs (instruction, loop, expression etc.)


== Resources ==
== Resources ==
Line 61: Line 71:
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] <br>
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] <br>
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle]<br>
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle]<br>
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle]
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle]<br>
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality]<br>
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture]

Revision as of 02:01, 30 November 2007

Bertrand Meyer is a prominent author in o-o design. He has developed a set of principles, many of which are embodied in the Eiffel language. Consider the principles of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle. What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?


Bertrand Meyer's Set of Principles

Bertrand Meyer is the developer of the Eiffel programming language. As a developer, Dr. Meyer participates in the evolution of the Eiffel method and language which includes a set of principles that he developed. Some of the more important principles are the principle of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle.

Principle of Small Interfaces

The principle of small interfaces, also known as weak coupling, states that if any two modules communicate at all, they should exchange as little information as possible.

Example of Principle of Small Interfaces

An ATM Example uses a Message class to encapsulate details of a Message from a Transaction to the bank. This is used as a parameter to the sendMessage() method of NetworkToBank - in place of a long list of specific parameters. This means that only the sending Transaction and receiving bank need to be aware of the details of the structure of a message - not the intermediate class(es) comprising the network.

Principle of Explicit Interfaces

The principle of explicit interfaces states that whenever two modules A and B communicate, this must be obvious from the text of A or B or both.

Example of Principle of Explicit Interfaces

Uniform-access Principle

The uniform-access principle states that 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.

Example of Uniform-access Principle

Ruby Programming language:

class Foo
 attr_reader :x
 def initialize(x)
   @x = x
 end
 def x_times_5
   return @x*5
 end
end
y = Foo.new(2)
puts y.x
puts y.x_times_5

This code outputs:

2
10

Note: Even though x is an attribute and x_times_5 is a parameterless method call, they're accessed the same way.

Self-documentation Principle

The designer of a module should strive to make all information about the module part of the module itself.

Example of Self-documentation Principle

Single-choice Principle

The single-choice principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.

Examples of Single-choice Principle

Example 1 - Editor: set of commands (insert, delete etc.) Example 2 - Graphics system: set of figure types (rectangle, circle etc.) Example 3 - Compiler: set of language constructs (instruction, loop, expression etc.)

Resources

Bertrand Meyer Wiki
List of Principles
Uniform-Access Principle
Single-Choice Principle
Design Quality
Software Architecture