Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T04:15:24Z

Cwlacewe: /* Self-documentation Principle */

'' 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? ''

__TOC__

== 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. The principle of small interfaces is supported by Java, C++ and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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. The principle of explicit interfaces is supported by Java, C++ and Eiffel. It is not difficult to follow this principle in any o-o languages.

====Example of Principle of Explicit Interfaces ====
[[Image:explicitinterface.jpg]]

===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. The uniform-access principle is supported by Java, Python Ruby and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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. Modules contain canonical minimal and complete documentation on their use. The self-documentation principle is supported by Eiffel. It is difficult to follow this principle in other o-o languages.

====Example of Self-documentation Principle ====
Eiffel provides superior support for this through:

Indexing Clauses

Class text begins with an indexing clause that contains a standardized but extensible set of tagged (searchable) lines describing various aspects of the class: 

indexing
description:
"Dispensers that provide access to only one item at a time."
status: "Todd Plessel, plessel@vislab.epa.gov"
names: "dispenser"
representation: "none"
access: "fixed", "membership"
contents: "generic"
date: "$Date: 1998/02/22 17:00:00 $"
revision: "$Revision: 1.0 $"

===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. The single-choice principle is supported by Java, Ruby and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture] 
[http://www.berenddeboer.net/eiffel/archive/why-eiffel.html Why Eiffel]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T04:12:58Z

Cwlacewe: /* Uniform-access Principle */

'' 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? ''

__TOC__

== 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. The principle of small interfaces is supported by Java, C++ and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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. The principle of explicit interfaces is supported by Java, C++ and Eiffel. It is not difficult to follow this principle in any o-o languages.

====Example of Principle of Explicit Interfaces ====
[[Image:explicitinterface.jpg]]

===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. The uniform-access principle is supported by Java, Python Ruby and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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. Modules contain canonical minimal and complete documentation on their use. The self-documentation principle is supported by Eiffel. It is not difficult to follow this principle in any o-o languages.

====Example of Self-documentation Principle ====
Eiffel provides superior support for this through:

Indexing Clauses

Class text begins with an indexing clause that contains a standardized but extensible set of tagged (searchable) lines describing various aspects of the class: 

indexing
description:
"Dispensers that provide access to only one item at a time."
status: "Todd Plessel, plessel@vislab.epa.gov"
names: "dispenser"
representation: "none"
access: "fixed", "membership"
contents: "generic"
date: "$Date: 1998/02/22 17:00:00 $"
revision: "$Revision: 1.0 $"

===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. The single-choice principle is supported by Java, Ruby and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture] 
[http://www.berenddeboer.net/eiffel/archive/why-eiffel.html Why Eiffel]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T04:11:56Z

Cwlacewe:

'' 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? ''

__TOC__

== 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. The principle of small interfaces is supported by Java, C++ and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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. The principle of explicit interfaces is supported by Java, C++ and Eiffel. It is not difficult to follow this principle in any o-o languages.

====Example of Principle of Explicit Interfaces ====
[[Image:explicitinterface.jpg]]

===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. The uniform-access principle is supported by Java, Ruby and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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. Modules contain canonical minimal and complete documentation on their use. The self-documentation principle is supported by Eiffel. It is not difficult to follow this principle in any o-o languages.

====Example of Self-documentation Principle ====
Eiffel provides superior support for this through:

Indexing Clauses

Class text begins with an indexing clause that contains a standardized but extensible set of tagged (searchable) lines describing various aspects of the class: 

indexing
description:
"Dispensers that provide access to only one item at a time."
status: "Todd Plessel, plessel@vislab.epa.gov"
names: "dispenser"
representation: "none"
access: "fixed", "membership"
contents: "generic"
date: "$Date: 1998/02/22 17:00:00 $"
revision: "$Revision: 1.0 $"

===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. The single-choice principle is supported by Java, Ruby and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture] 
[http://www.berenddeboer.net/eiffel/archive/why-eiffel.html Why Eiffel]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T04:10:14Z

Cwlacewe:

'' 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? ''

__TOC__

== 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. The principle of small interfaces is supported by Java, and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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. The principle of explicit interfaces is supported by Java, and Eiffel. It is not difficult to follow this principle in any o-o languages.

====Example of Principle of Explicit Interfaces ====
[[Image:explicitinterface.jpg]]

===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. The uniform-access principle is supported by Java, Ruby and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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. Modules contain canonical minimal and complete documentation on their use. The self-documentation principle is supported by Eiffel. It is not difficult to follow this principle in any o-o languages.

====Example of Self-documentation Principle ====
Eiffel provides superior support for this through:

Indexing Clauses

Class text begins with an indexing clause that contains a standardized but extensible set of tagged (searchable) lines describing various aspects of the class: 

indexing
description:
"Dispensers that provide access to only one item at a time."
status: "Todd Plessel, plessel@vislab.epa.gov"
names: "dispenser"
representation: "none"
access: "fixed", "membership"
contents: "generic"
date: "$Date: 1998/02/22 17:00:00 $"
revision: "$Revision: 1.0 $"

===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. The single-choice principle is supported by Java, Ruby and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture] 
[http://www.berenddeboer.net/eiffel/archive/why-eiffel.html Why Eiffel]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T03:41:56Z

Cwlacewe:

'' 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? ''

__TOC__

== 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. The principle of small interfaces is supported by Java, and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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. The principle of explicit interfaces is supported by Java, and Eiffel. It is not difficult to follow this principle in any o-o languages.

====Example of Principle of Explicit Interfaces ====
[[Image:explicitinterface.jpg]]

===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. The uniform-access principle is supported by Java, and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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. Modules contain canonical minimal and complete documentation on their use. The self-documentation principle is supported by Java, and Eiffel. It is not difficult to follow this principle in any o-o languages.

====Example of Self-documentation Principle ====
Eiffel provides superior support for this through:

Indexing Clauses

Class text begins with an indexing clause that contains a standardized but extensible set of tagged (searchable) lines describing various aspects of the class: 

indexing
description:
"Dispensers that provide access to only one item at a time."
status: "Todd Plessel, plessel@vislab.epa.gov"
names: "dispenser"
representation: "none"
access: "fixed", "membership"
contents: "generic"
date: "$Date: 1998/02/22 17:00:00 $"
revision: "$Revision: 1.0 $"

===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. The single-choice principle is supported by Java, and Eiffel. It is not difficult to follow this principle in any o-o languages.

====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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture] 
[http://www.berenddeboer.net/eiffel/archive/why-eiffel.html Why Eiffel]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T03:32:22Z

Cwlacewe: /* Resources */

'' 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? ''

__TOC__

== 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 ====
[[Image:explicitinterface.jpg]]

===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. Modules contain canonical minimal and complete documentation on their use.

====Example of Self-documentation Principle ====
Eiffel provides superior support for this through:

Indexing Clauses

Class text begins with an indexing clause that contains a standardized but extensible set of tagged (searchable) lines describing various aspects of the class: 

indexing
description:
"Dispensers that provide access to only one item at a time."
status: "Todd Plessel, plessel@vislab.epa.gov"
names: "dispenser"
representation: "none"
access: "fixed", "membership"
contents: "generic"
date: "$Date: 1998/02/22 17:00:00 $"
revision: "$Revision: 1.0 $"

===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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture] 
[http://www.berenddeboer.net/eiffel/archive/why-eiffel.html Why Eiffel]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T03:29:12Z

Cwlacewe: /* Example of Self-documentation Principle */

'' 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? ''

__TOC__

== 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 ====
[[Image:explicitinterface.jpg]]

===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. Modules contain canonical minimal and complete documentation on their use.

====Example of Self-documentation Principle ====
Eiffel provides superior support for this through:

Indexing Clauses

Class text begins with an indexing clause that contains a standardized but extensible set of tagged (searchable) lines describing various aspects of the class: 

indexing
description:
"Dispensers that provide access to only one item at a time."
status: "Todd Plessel, plessel@vislab.epa.gov"
names: "dispenser"
representation: "none"
access: "fixed", "membership"
contents: "generic"
date: "$Date: 1998/02/22 17:00:00 $"
revision: "$Revision: 1.0 $"

===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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T03:28:35Z

Cwlacewe: /* Example of Self-documentation Principle */

'' 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? ''

__TOC__

== 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 ====
[[Image:explicitinterface.jpg]]

===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. Modules contain canonical minimal and complete documentation on their use.

====Example of Self-documentation Principle ====
Eiffel provides superior support for this through:

Indexing Clauses

Class text begins with an indexing clause that contains a standardized but extensible set of tagged (searchable) lines describing various aspects of the class:

indexing
description:
"Dispensers that provide access to only one item at a time."
status: "Todd Plessel, plessel@vislab.epa.gov"
names: "dispenser"
representation: "none"
access: "fixed", "membership"
contents: "generic"
date: "$Date: 1998/02/22 17:00:00 $"
revision: "$Revision: 1.0 $"

===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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T03:28:19Z

Cwlacewe: /* Example of Self-documentation Principle */

'' 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? ''

__TOC__

== 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 ====
[[Image:explicitinterface.jpg]]

===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. Modules contain canonical minimal and complete documentation on their use.

====Example of Self-documentation Principle ====
Eiffel provides superior support for this through:

Indexing Clauses

Class text begins with an indexing clause that contains a standardized but extensible set of tagged (searchable) lines describing various aspects of the class:

indexing
description:
"Dispensers that provide access to only one item at a time."
status: "Todd Plessel, plessel@vislab.epa.gov"
names: "dispenser"
representation: "none"
access: "fixed", "membership"
contents: "generic"
date: "$Date: 1998/02/22 17:00:00 $"
revision: "$Revision: 1.0 $"

===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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T03:27:46Z

Cwlacewe: /* Self-documentation Principle */

'' 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? ''

__TOC__

== 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 ====
[[Image:explicitinterface.jpg]]

===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. Modules contain canonical minimal and complete documentation on their use.

====Example of Self-documentation Principle ====
Eiffel provides superior support for this through:

Indexing Clauses

Class text begins with an indexing clause that contains a standardized but extensible set of tagged (searchable) lines describing various aspects of the class:

indexing

description:
"Dispensers that provide access to only one item at a time."
status: "Todd Plessel, plessel@vislab.epa.gov"
names: "dispenser"
representation: "none"
access: "fixed", "membership"
contents: "generic"
date: "$Date: 1998/02/22 17:00:00 $"
revision: "$Revision: 1.0 $"

===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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T02:01:38Z

Cwlacewe: /* Examples of Single-choice Principle */

'' 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? ''

__TOC__

== 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 ====
[[Image:explicitinterface.jpg]]

===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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture]

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-30T02:01:14Z

Cwlacewe:

'' 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? ''

__TOC__

== 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 ====
[[Image:explicitinterface.jpg]]

===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 ==
[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer Wiki] 
[http://www.cs.wustl.edu/~levine/courses/cs342/c++/design-principles_4.pdf List of Principles] 
[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform-Access Principle] 
[http://en.wikipedia.org/wiki/Single_choice_principle Single-Choice Principle] 
[http://www.cs.gordon.edu/local/courses/cs211/lectures-2005/DesignQuality.pdf Design Quality] 
[http://wiki.vis.ethz.ch/Zusammenfassung_Software_Architecture Software Architecture]

File:Explicitinterface.jpg

2007-11-29T19:48:59Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-29T19:48:33Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-18T00:52:45Z

Cwlacewe: /* Resources */

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-18T00:51:42Z

Cwlacewe: /* Single-choice Principle */

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-18T00:45:43Z

Cwlacewe: /* Single-choice Principle */

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-18T00:44:05Z

Cwlacewe: /* Self-documentation Principle */

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-17T21:31:01Z

Cwlacewe: /* Example of Uniform-access Principle */

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-17T21:28:51Z

Cwlacewe: /* Example of Uniform-access Principle */

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-17T21:28:23Z

Cwlacewe: /* Example of Uniform-access Principle */

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-17T21:27:37Z

Cwlacewe: /* Example of Uniform-access Principle */

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-17T21:26:59Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-16T22:03:17Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-16T21:57:13Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-16T21:37:30Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki3 7 cl

2007-11-16T18:43:32Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki2 10 cv

2007-10-24T17:14:13Z

Cwlacewe:

''Inheritance vs. delegation. Follow the debate on inheritance vs. delegation. Construct (or, better, cite) examples that show cases where inheritance is better, and cases where delegation is better. Attempt to characterize the situations in which you should employ one or the other.''

__TOC__

==Inheritance==
Inheritance is a way to form new classes in object oriented programming using already defined classes. Inheritance is used to help reuse code that already exists with little or no modifications and this is one of the advantages of using inheritance since it helps reduce the complexity of a program. MAny programmers are confused on when to use inheritance but inheritance is mainly used when a programmers new class can be used in place of the existing class and the relationship between them can be described as an is-a relationship.

===Advantages and Disadvantages of Inheritance===
Advantages of Inheritance: 
- Straightforward to use 
- Supported by many programming languages 
- Easy to implement new functionality 

Disadvantages of Inheritance: 
- Exposes a subclass to the details of its parent class 
- Changes in the parent class implementation would cause the subclass to change as well 

==Delegation==
Delegation is when one object relies on another object in order to provide a specified set of functionalities and this is sometimes referred to as aggregation, consultation, or forwarding. It is better to use delegation when a programmers new class needs to use the existing class and the relationship can be described as a has-a or uses-a relationship.

===Advantages and Disadvantages of Delegation===
Advantages of Delegation: 
- Provides flexibility due to the fact that any object can be replaced at run time by another one of the same type 

Disadvantages of Delegation: 
- Is efficient since objects are encapsulated 

== Examples of Delegation and Inheritance ==

The following section discusses the examples explaining the usage of Inheritance and Delegates and how they can be used in specific situations. Also, it talks about the pros and cons of using these models by taking a common example.

=== Where Delegation makes more sense than Inheritance ===

==== The Game Example ====

Consider a game with different difficulty levels. Now suppose we have two kind of player levels smart and dumb. Here the requirement is that it is possible to change the difficulty level of the game at any time. We can construct two models to solve this problem, one with inheritance and the other with delegation.

Inheritance Model
[[Image:modelA.jpg]]

Delegation Model
[[Image:modelB.jpg]]

In model A, the client of the computer player much know when to create to create the instances of an appropriate class when switching from difficult to simple mode or vice versa. The trouble here is that in Inheritance, once the object instance is created its type can not be changed at later time.
Inheritance allows polymorphism, which provides a kind of run-time flexibility, but this model is undesirable. Client code to change the difficulty level at run-time is very complicated, and requires detailed knowledge of the computer player’s implementation classes.

On the other hand in model B, it is possible for class ComputerPlayer to have a simple setDifficulty() method. This can be done using delegation and at runtime using this method we can chance the difficulty level of the game.
Therefore, delegation is a dynamic relationship, providing a different kind of runtime flexibility in the code, compared to inheritance.

=== Where Inheritance makes more sense than Delegation ===

==== An example ====

Inheritance is generally used when an object derives all of the properties of the base object. This is done at compile time and hence cannot be changed at runtime.

Suppose you have a class

== References ==
[http://users.encs.concordia.ca/~hshong/comp6471/ch5-2.ppt Inheritance vs. Delegation] 
[http://media.pragprog.com/titles/pad/CodeAndDebug.pdf Practices of an Agile Developer]

CSC/ECE 517 Fall 2007/wiki2 10 cv

2007-10-23T04:39:18Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki2 10 cv

2007-10-23T04:11:30Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T04:11:12Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T03:44:53Z

Cwlacewe: /* References */

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T03:44:34Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T03:38:06Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T03:25:42Z

Cwlacewe: /* Inheritance vs. Delegation */

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T03:24:32Z

Cwlacewe: /* Inheritance vs. Delegation */

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T03:13:24Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T02:33:30Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T02:24:01Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T02:10:21Z

Cwlacewe: /* References */

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T02:09:41Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T01:53:56Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki2 9 cv

2007-10-23T01:52:40Z

Cwlacewe:

CSC/ECE 517 Fall 2007/wiki1b 6 c1

2007-10-11T00:43:38Z

Cwlacewe: /* External Links */

''Take a case of the Singleton pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived.''

__TOC__

== Singleton Pattern ==
The Singleton Pattern is a design pattern used to insure the existence of a single instance of a class in the run time. It constructs the object once and returns a reference to this object every time thereafter. In a multithreading environment, special care should be taken.

===Global Variables versus Singleton===
Singletons are often mistaken as global variables. These two are very similar but the main difference between the two is that the Singleton Pattern deals with how to limit instances, while global variables deal with how programmers declare instances. When programming, one should not think that the use of Singleton Pattern would solve problems that are associated with global variables because this is a common mistake.

===Benefits of Singleton Pattern===
There are benefits of using the singleton pattern over other patterns and global variables. When using Singleton Pattern it allows instance control by preventing other objects from instantiating their own copies of the Singleton object which would ensure that all objects access the single instance. Using the Singleton Pattern also gives a little flexibility since the class controls the instantiation process and has the flexibility to change the instantiation process. Singleton Pattern allows reduced name space because the Singleton class can be subclassed,which makes it easier to configure an application with an instance of this extended class. The application can be configures with an instance of the class one needs at run-time. 
Several uses of Singleton Pattern include logger (which is illustrated below), payment form, application preference, many dialogs in GUI environemt, and etc.

==Class Diagram==
[[Image:singleton.png]]

== Implementation ==
To implement Singleton do following steps 
1- Turn your class constructor to private 
2- Create a public method -getInstance()- to return a refrence to the instance. If the object is not initialized yet (object == null) it will create one by invoking the constructor. 
3- In multithreading environment, synchoranize your getInstance() method so you don't end with Doubleton or Tripleton. 
4- Consider overiding the clone method in Java, so no one can copy your Singleton. 

In multithreading environment, a synchronized command should be used so not every thread in the program can initialize its own instance of the singleton class.

=== Example Implementations ===
To demonstrate further let us consider programs that implement a logger in Java and then in Ruby.

====Java====

public class LoggerSingleton {
private static LoggerSingleton instance = null;
private LoggerSingleton() {
// Exists only to defeat instantiation.
}
public static synchronized LoggerSingleton getInstance() {
if(instance == null) {
instance = new LoggerSingleton();
}
return instance;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
// add other attributes
}

or consider simpler implementation in Java, 

public class LoggerSingleton {
private final static LoggerSingleton instance = new Singleton();

private LoggerSingleton () {
}

public static LoggerSingleton getInstance() {
return instance ;
}
}

====Ruby====

or for sure the super simple in Ruby,

require 'singleton'
class LoggerSingleton
include Singleton
end

===Invoking Singletons===

The following coding is to invoke a singleton class in Java then in Ruby

====Java====

LoggerSingleton logger1 = LoggerSingleton.getInstance();
LoggerSingleton logger2 = LoggerSingleton.getInstance();
LoggerSingleton logger3 = new LoggerSingleton(); // compilation error will occur; The constructor is private.
System.out.println(logger1);
System.out.println(logger2);

====Ruby====

logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance

===Test Singletons===

The following coding is to test singleton class in Java then in Ruby

====Java====

import junit.framework.Assert;
import junit.framework.TestCase;
public class TestSingleton extends TestCase {
private LoggerSingleton logger1 = null, logger2 = null;
public TestSingleton(String name) {
super(name);
}
public void setUp() {
logger1 = LoggerSingleton.getInstance();
logger2 = LoggerSingleton.getInstance();
}
public void testUnique() {
System.out.println(logger1);
System.out.println(logger2);
Assert.assertEquals(true, logger1 == logger2);
}
}

====Ruby====

def testSingleton
logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance
assertEqual logger1, logger2
end

== Comparison ==
When comparing Singleton Pattern in Java and Ruby, it is shown that Ruby obviously is better than Java. It seems that Ruby would win because of the simplicity compared to Java since only one line of code "include Singleton" enables all the functionalities when Java needs more lines to do this. Since Ruby uses singleton mixins, it is easier to implemenet and since Java does not use mixins, it requires more implementation in the coding.

== Conclusion ==
Java doesn’t contain singleton pattern in the language itself, although implementation for the pattern is still possible. While in Ruby the singleton pattern is in the language itself, which became possible since Ruby is a dynamic language through singleton module.

== References ==
Head First Design Patterns by Eric Freeman, Kathy Sierra, Bert Bates, Elisabeth Freeman 
Programming Ruby: The Pragmatic Programmers' Guide (Pragmatic Programmers Series) by Dave Thomas, Andy Hunt, Andrew Hunt, Chad Fowler, Chad Fowler

=== External Links ===
[http://en.wikipedia.org/wiki/Singleton_pattern Singleton Pattern Wiki] 
[http://c2.com/cgi/wiki?SingletonPattern Singleton Article]

CSC/ECE 517 Fall 2007/wiki1b 6 c1

2007-10-11T00:42:29Z

Cwlacewe: /* External Links */

''Take a case of the Singleton pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived.''

__TOC__

== Singleton Pattern ==
The Singleton Pattern is a design pattern used to insure the existence of a single instance of a class in the run time. It constructs the object once and returns a reference to this object every time thereafter. In a multithreading environment, special care should be taken.

===Global Variables versus Singleton===
Singletons are often mistaken as global variables. These two are very similar but the main difference between the two is that the Singleton Pattern deals with how to limit instances, while global variables deal with how programmers declare instances. When programming, one should not think that the use of Singleton Pattern would solve problems that are associated with global variables because this is a common mistake.

===Benefits of Singleton Pattern===
There are benefits of using the singleton pattern over other patterns and global variables. When using Singleton Pattern it allows instance control by preventing other objects from instantiating their own copies of the Singleton object which would ensure that all objects access the single instance. Using the Singleton Pattern also gives a little flexibility since the class controls the instantiation process and has the flexibility to change the instantiation process. Singleton Pattern allows reduced name space because the Singleton class can be subclassed,which makes it easier to configure an application with an instance of this extended class. The application can be configures with an instance of the class one needs at run-time. 
Several uses of Singleton Pattern include logger (which is illustrated below), payment form, application preference, many dialogs in GUI environemt, and etc.

==Class Diagram==
[[Image:singleton.png]]

== Implementation ==
To implement Singleton do following steps 
1- Turn your class constructor to private 
2- Create a public method -getInstance()- to return a refrence to the instance. If the object is not initialized yet (object == null) it will create one by invoking the constructor. 
3- In multithreading environment, synchoranize your getInstance() method so you don't end with Doubleton or Tripleton. 
4- Consider overiding the clone method in Java, so no one can copy your Singleton. 

In multithreading environment, a synchronized command should be used so not every thread in the program can initialize its own instance of the singleton class.

=== Example Implementations ===
To demonstrate further let us consider programs that implement a logger in Java and then in Ruby.

====Java====

public class LoggerSingleton {
private static LoggerSingleton instance = null;
private LoggerSingleton() {
// Exists only to defeat instantiation.
}
public static synchronized LoggerSingleton getInstance() {
if(instance == null) {
instance = new LoggerSingleton();
}
return instance;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
// add other attributes
}

or consider simpler implementation in Java, 

public class LoggerSingleton {
private final static LoggerSingleton instance = new Singleton();

private LoggerSingleton () {
}

public static LoggerSingleton getInstance() {
return instance ;
}
}

====Ruby====

or for sure the super simple in Ruby,

require 'singleton'
class LoggerSingleton
include Singleton
end

===Invoking Singletons===

The following coding is to invoke a singleton class in Java then in Ruby

====Java====

LoggerSingleton logger1 = LoggerSingleton.getInstance();
LoggerSingleton logger2 = LoggerSingleton.getInstance();
LoggerSingleton logger3 = new LoggerSingleton(); // compilation error will occur; The constructor is private.
System.out.println(logger1);
System.out.println(logger2);

====Ruby====

logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance

===Test Singletons===

The following coding is to test singleton class in Java then in Ruby

====Java====

import junit.framework.Assert;
import junit.framework.TestCase;
public class TestSingleton extends TestCase {
private LoggerSingleton logger1 = null, logger2 = null;
public TestSingleton(String name) {
super(name);
}
public void setUp() {
logger1 = LoggerSingleton.getInstance();
logger2 = LoggerSingleton.getInstance();
}
public void testUnique() {
System.out.println(logger1);
System.out.println(logger2);
Assert.assertEquals(true, logger1 == logger2);
}
}

====Ruby====

def testSingleton
logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance
assertEqual logger1, logger2
end

== Comparison ==
When comparing Singleton Pattern in Java and Ruby, it is shown that Ruby obviously is better than Java. It seems that Ruby would win because of the simplicity compared to Java since only one line of code "include Singleton" enables all the functionalities when Java needs more lines to do this. Since Ruby uses singleton mixins, it is easier to implemenet and since Java does not use mixins, it requires more implementation in the coding.

== Conclusion ==
Java doesn’t contain singleton pattern in the language itself, although implementation for the pattern is still possible. While in Ruby the singleton pattern is in the language itself, which became possible since Ruby is a dynamic language through singleton module.

== References ==
Head First Design Patterns by Eric Freeman, Kathy Sierra, Bert Bates, Elisabeth Freeman 
Programming Ruby: The Pragmatic Programmers' Guide (Pragmatic Programmers Series) by Dave Thomas, Andy Hunt, Andrew Hunt, Chad Fowler, Chad Fowler

=== External Links ===
[http://en.wikipedia.org/wiki/Singleton_pattern Singleton Pattern Wiki] 
[http://www.mrchucho.net/index.php/archives/2006/10/ Singleton Article]

CSC/ECE 517 Fall 2007/wiki1b 6 c1

2007-10-11T00:42:02Z

Cwlacewe: /* External Links */

''Take a case of the Singleton pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived.''

__TOC__

== Singleton Pattern ==
The Singleton Pattern is a design pattern used to insure the existence of a single instance of a class in the run time. It constructs the object once and returns a reference to this object every time thereafter. In a multithreading environment, special care should be taken.

===Global Variables versus Singleton===
Singletons are often mistaken as global variables. These two are very similar but the main difference between the two is that the Singleton Pattern deals with how to limit instances, while global variables deal with how programmers declare instances. When programming, one should not think that the use of Singleton Pattern would solve problems that are associated with global variables because this is a common mistake.

===Benefits of Singleton Pattern===
There are benefits of using the singleton pattern over other patterns and global variables. When using Singleton Pattern it allows instance control by preventing other objects from instantiating their own copies of the Singleton object which would ensure that all objects access the single instance. Using the Singleton Pattern also gives a little flexibility since the class controls the instantiation process and has the flexibility to change the instantiation process. Singleton Pattern allows reduced name space because the Singleton class can be subclassed,which makes it easier to configure an application with an instance of this extended class. The application can be configures with an instance of the class one needs at run-time. 
Several uses of Singleton Pattern include logger (which is illustrated below), payment form, application preference, many dialogs in GUI environemt, and etc.

==Class Diagram==
[[Image:singleton.png]]

== Implementation ==
To implement Singleton do following steps 
1- Turn your class constructor to private 
2- Create a public method -getInstance()- to return a refrence to the instance. If the object is not initialized yet (object == null) it will create one by invoking the constructor. 
3- In multithreading environment, synchoranize your getInstance() method so you don't end with Doubleton or Tripleton. 
4- Consider overiding the clone method in Java, so no one can copy your Singleton. 

In multithreading environment, a synchronized command should be used so not every thread in the program can initialize its own instance of the singleton class.

=== Example Implementations ===
To demonstrate further let us consider programs that implement a logger in Java and then in Ruby.

====Java====

public class LoggerSingleton {
private static LoggerSingleton instance = null;
private LoggerSingleton() {
// Exists only to defeat instantiation.
}
public static synchronized LoggerSingleton getInstance() {
if(instance == null) {
instance = new LoggerSingleton();
}
return instance;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
// add other attributes
}

or consider simpler implementation in Java, 

public class LoggerSingleton {
private final static LoggerSingleton instance = new Singleton();

private LoggerSingleton () {
}

public static LoggerSingleton getInstance() {
return instance ;
}
}

====Ruby====

or for sure the super simple in Ruby,

require 'singleton'
class LoggerSingleton
include Singleton
end

===Invoking Singletons===

The following coding is to invoke a singleton class in Java then in Ruby

====Java====

LoggerSingleton logger1 = LoggerSingleton.getInstance();
LoggerSingleton logger2 = LoggerSingleton.getInstance();
LoggerSingleton logger3 = new LoggerSingleton(); // compilation error will occur; The constructor is private.
System.out.println(logger1);
System.out.println(logger2);

====Ruby====

logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance

===Test Singletons===

The following coding is to test singleton class in Java then in Ruby

====Java====

import junit.framework.Assert;
import junit.framework.TestCase;
public class TestSingleton extends TestCase {
private LoggerSingleton logger1 = null, logger2 = null;
public TestSingleton(String name) {
super(name);
}
public void setUp() {
logger1 = LoggerSingleton.getInstance();
logger2 = LoggerSingleton.getInstance();
}
public void testUnique() {
System.out.println(logger1);
System.out.println(logger2);
Assert.assertEquals(true, logger1 == logger2);
}
}

====Ruby====

def testSingleton
logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance
assertEqual logger1, logger2
end

== Comparison ==
When comparing Singleton Pattern in Java and Ruby, it is shown that Ruby obviously is better than Java. It seems that Ruby would win because of the simplicity compared to Java since only one line of code "include Singleton" enables all the functionalities when Java needs more lines to do this. Since Ruby uses singleton mixins, it is easier to implemenet and since Java does not use mixins, it requires more implementation in the coding.

== Conclusion ==
Java doesn’t contain singleton pattern in the language itself, although implementation for the pattern is still possible. While in Ruby the singleton pattern is in the language itself, which became possible since Ruby is a dynamic language through singleton module.

== References ==
Head First Design Patterns by Eric Freeman, Kathy Sierra, Bert Bates, Elisabeth Freeman 
Programming Ruby: The Pragmatic Programmers' Guide (Pragmatic Programmers Series) by Dave Thomas, Andy Hunt, Andrew Hunt, Chad Fowler, Chad Fowler

=== External Links ===
[http://en.wikipedia.org/wiki/Singleton_pattern Singleton Pattern Wiki]
[http://www.mrchucho.net/index.php/archives/2006/10/ Singleton Article]

CSC/ECE 517 Fall 2007/wiki1b 6 c1

2007-10-11T00:40:19Z

Cwlacewe: /* Singleton Pattern */

CSC/ECE 517 Fall 2007/wiki1b 6 c1

2007-10-10T23:22:01Z

Cwlacewe: /* References */

''Take a case of the Singleton pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived.''

__TOC__

== Singleton Pattern ==
The Singleton pattern is a design pattern used to insure the existence of a single instance of a class in the run time. It constructs the object once and returns a reference to this object every time thereafter. In a multithreading environment, special care should be taken.

===Global Variables versus Singleton===
Singletons are often mistaken as global variables. These two are very similar but the main difference between the two is that the Singleton Pattern deals with how to limit instances, while global variables deal with how programmers declare instances. When programming, one should not think that the use of Singleton Pattern would solve problems that are associated with global variables because this is a common mistake.

===Benefits of Singleton Pattern===
There are benefits of using the singleton pattern over other patterns and global variables. When using Singleton Pattern it allows instance control by preventing other objects from instantiating their own copies of the Singleton object which would ensure that all objects access the single instance. Using the Singleton Pattern also gives a little flexibility since the class controls the instantiation process and has the flexibility to change the instantiation process. Singleton Pattern allows reduced name space because the Singleton class can be subclassed,which makes it easier to configure an application with an instance of this extended class. The application can be configures with an instance of the class one needs at run-time. 
Several uses of Singleton Pattern include logger (which is illustrated below), payment form, application preference, many dialogs in GUI environemt, and etc.

==Class Diagram==
[[Image:singleton.png]]

== Implementation ==
To implement Singleton do following steps 
1- Turn your class constructor to private 
2- Create a public method -getInstance()- to return a refrence to the instance. If the object is not initialized yet (object == null) it will create one by invoking the constructor. 
3- In multithreading environment, synchoranize your getInstance() method so you don't end with Doubleton or Tripleton. 
4- Consider overiding the clone method in Java, so no one can copy your Singleton. 

In multithreading environment, a synchronized command should be used so not every thread in the program can initialize its own instance of the singleton class.

=== Example Implementations ===
To demonstrate further let us consider programs that implement a logger in Java and then in Ruby.

====Java====

public class LoggerSingleton {
private static LoggerSingleton instance = null;
private LoggerSingleton() {
// Exists only to defeat instantiation.
}
public static synchronized LoggerSingleton getInstance() {
if(instance == null) {
instance = new LoggerSingleton();
}
return instance;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
// add other attributes
}

or consider simpler implementation in Java, 

public class LoggerSingleton {
private final static LoggerSingleton instance = new Singleton();

private LoggerSingleton () {
}

public static LoggerSingleton getInstance() {
return instance ;
}
}

====Ruby====

or for sure the super simple in Ruby,

require 'singleton'
class LoggerSingleton
include Singleton
end

===Invoking Singletons===

The following coding is to invoke a singleton class in Java then in Ruby

====Java====

LoggerSingleton logger1 = LoggerSingleton.getInstance();
LoggerSingleton logger2 = LoggerSingleton.getInstance();
LoggerSingleton logger3 = new LoggerSingleton(); // compilation error will occur; The constructor is private.
System.out.println(logger1);
System.out.println(logger2);

====Ruby====

logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance

===Test Singletons===

The following coding is to test singleton class in Java then in Ruby

====Java====

import junit.framework.Assert;
import junit.framework.TestCase;
public class TestSingleton extends TestCase {
private LoggerSingleton logger1 = null, logger2 = null;
public TestSingleton(String name) {
super(name);
}
public void setUp() {
logger1 = LoggerSingleton.getInstance();
logger2 = LoggerSingleton.getInstance();
}
public void testUnique() {
System.out.println(logger1);
System.out.println(logger2);
Assert.assertEquals(true, logger1 == logger2);
}
}

====Ruby====

def testSingleton
logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance
assertEqual logger1, logger2
end

== Comparison ==
When comparing Singleton Pattern in Java and Ruby, it is shown that Ruby obviously is better than Java. It seems that Ruby would win because of the simplicity compared to Java since only one line of code "include Singleton" enables all the functionalities when Java needs more lines to do this. Since Ruby uses singleton mixins, it is easier to implemenet and since Java does not use mixins, it requires more implementation in the coding.

== Conclusion ==
Java doesn’t contain singleton pattern in the language itself, although implementation for the pattern is still possible. While in Ruby the singleton pattern is in the language itself, which became possible since Ruby is a dynamic language through singleton module.

== References ==
Head First Design Patterns by Eric Freeman, Kathy Sierra, Bert Bates, Elisabeth Freeman 
Programming Ruby: The Pragmatic Programmers' Guide (Pragmatic Programmers Series) by Dave Thomas, Andy Hunt, Andrew Hunt, Chad Fowler, Chad Fowler

=== External Links ===
[http://en.wikipedia.org/wiki/Singleton_pattern Singleton Pattern Wiki]

CSC/ECE 517 Fall 2007/wiki1b 6 c1

2007-10-10T23:20:57Z

Cwlacewe: /* Global Variables versus Singleton */

''Take a case of the Singleton pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived.''

__TOC__

== Singleton Pattern ==
The Singleton pattern is a design pattern used to insure the existence of a single instance of a class in the run time. It constructs the object once and returns a reference to this object every time thereafter. In a multithreading environment, special care should be taken.

===Global Variables versus Singleton===
Singletons are often mistaken as global variables. These two are very similar but the main difference between the two is that the Singleton Pattern deals with how to limit instances, while global variables deal with how programmers declare instances. When programming, one should not think that the use of Singleton Pattern would solve problems that are associated with global variables because this is a common mistake.

===Benefits of Singleton Pattern===
There are benefits of using the singleton pattern over other patterns and global variables. When using Singleton Pattern it allows instance control by preventing other objects from instantiating their own copies of the Singleton object which would ensure that all objects access the single instance. Using the Singleton Pattern also gives a little flexibility since the class controls the instantiation process and has the flexibility to change the instantiation process. Singleton Pattern allows reduced name space because the Singleton class can be subclassed,which makes it easier to configure an application with an instance of this extended class. The application can be configures with an instance of the class one needs at run-time. 
Several uses of Singleton Pattern include logger (which is illustrated below), payment form, application preference, many dialogs in GUI environemt, and etc.

==Class Diagram==
[[Image:singleton.png]]

== Implementation ==
To implement Singleton do following steps 
1- Turn your class constructor to private 
2- Create a public method -getInstance()- to return a refrence to the instance. If the object is not initialized yet (object == null) it will create one by invoking the constructor. 
3- In multithreading environment, synchoranize your getInstance() method so you don't end with Doubleton or Tripleton. 
4- Consider overiding the clone method in Java, so no one can copy your Singleton. 

In multithreading environment, a synchronized command should be used so not every thread in the program can initialize its own instance of the singleton class.

=== Example Implementations ===
To demonstrate further let us consider programs that implement a logger in Java and then in Ruby.

====Java====

public class LoggerSingleton {
private static LoggerSingleton instance = null;
private LoggerSingleton() {
// Exists only to defeat instantiation.
}
public static synchronized LoggerSingleton getInstance() {
if(instance == null) {
instance = new LoggerSingleton();
}
return instance;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
// add other attributes
}

or consider simpler implementation in Java, 

public class LoggerSingleton {
private final static LoggerSingleton instance = new Singleton();

private LoggerSingleton () {
}

public static LoggerSingleton getInstance() {
return instance ;
}
}

====Ruby====

or for sure the super simple in Ruby,

require 'singleton'
class LoggerSingleton
include Singleton
end

===Invoking Singletons===

The following coding is to invoke a singleton class in Java then in Ruby

====Java====

LoggerSingleton logger1 = LoggerSingleton.getInstance();
LoggerSingleton logger2 = LoggerSingleton.getInstance();
LoggerSingleton logger3 = new LoggerSingleton(); // compilation error will occur; The constructor is private.
System.out.println(logger1);
System.out.println(logger2);

====Ruby====

logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance

===Test Singletons===

The following coding is to test singleton class in Java then in Ruby

====Java====

import junit.framework.Assert;
import junit.framework.TestCase;
public class TestSingleton extends TestCase {
private LoggerSingleton logger1 = null, logger2 = null;
public TestSingleton(String name) {
super(name);
}
public void setUp() {
logger1 = LoggerSingleton.getInstance();
logger2 = LoggerSingleton.getInstance();
}
public void testUnique() {
System.out.println(logger1);
System.out.println(logger2);
Assert.assertEquals(true, logger1 == logger2);
}
}

====Ruby====

def testSingleton
logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance
assertEqual logger1, logger2
end

== Comparison ==
When comparing Singleton Pattern in Java and Ruby, it is shown that Ruby obviously is better than Java. It seems that Ruby would win because of the simplicity compared to Java since only one line of code "include Singleton" enables all the functionalities when Java needs more lines to do this. Since Ruby uses singleton mixins, it is easier to implemenet and since Java does not use mixins, it requires more implementation in the coding.

== Conclusion ==
Java doesn’t contain singleton pattern in the language itself, although implementation for the pattern is still possible. While in Ruby the singleton pattern is in the language itself, which became possible since Ruby is a dynamic language through singleton module.

== References ==
Head First Design Patterns by Eric Freeman, Kathy Sierra, Bert Bates, Elisabeth Freeman 
Programming Ruby: The Pragmatic Programmers' Guide (Pragmatic Programmers Series) by Dave Thomas, Andy Hunt, Andrew Hunt, Chad Fowler, Chad Fowler

=== External Links ===
[http://en.wikipedia.org/wiki/Singleton_pattern Singleton Pattern Wiki]

CSC/ECE 517 Fall 2007/wiki1b 6 c1

2007-10-10T17:40:16Z

Cwlacewe:

''Take a case of the Singleton pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived.''

__TOC__

== Singleton Pattern ==
The Singleton pattern is a design pattern used to insure the existence of a single instance of a class in the run time. It constructs the object once and returns a reference to this object every time thereafter. In a multithreading environment, special care should be taken.

===Global Variables versus Singleton===
Singletons are often mistaken as global variables. These two are very similar but the main difference between the two is that the Singleton Pattern deals with how to limit instances, while global variables deal with how programmers declare instances. Singletons are frequently mistaken by programmers that are inexperienced because they usually think that the use of Singleton Pattern will solve problems that are associated with global variables.

===Benefits of Singleton Pattern===
There are benefits of using the singleton pattern over other patterns and global variables. When using Singleton Pattern it allows instance control by preventing other objects from instantiating their own copies of the Singleton object which would ensure that all objects access the single instance. Using the Singleton Pattern also gives a little flexibility since the class controls the instantiation process and has the flexibility to change the instantiation process. Singleton Pattern allows reduced name space because the Singleton class can be subclassed,which makes it easier to configure an application with an instance of this extended class. The application can be configures with an instance of the class one needs at run-time. 
Several uses of Singleton Pattern include logger (which is illustrated below), payment form, application preference, many dialogs in GUI environemt, and etc.

==Class Diagram==
[[Image:singleton.png]]

== Implementation ==
To implement Singleton do following steps 
1- Turn your class constructor to private 
2- Create a public method -getInstance()- to return a refrence to the instance. If the object is not initialized yet (object == null) it will create one by invoking the constructor. 
3- In multithreading environment, synchoranize your getInstance() method so you don't end with Doubleton or Tripleton. 
4- Consider overiding the clone method in Java, so no one can copy your Singleton. 

In multithreading environment, a synchronized command should be used so not every thread in the program can initialize its own instance of the singleton class.

=== Example Implementations ===
To demonstrate further let us consider programs that implement a logger in Java and then in Ruby.

Java

public class LoggerSingleton {
private static LoggerSingleton instance = null;
private LoggerSingleton() {
// Exists only to defeat instantiation.
}
public static synchronized LoggerSingleton getInstance() {
if(instance == null) {
instance = new LoggerSingleton();
}
return instance;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
// add other attributes
}

or consider simpler implementation in Java,

public class LoggerSingleton {
private final static LoggerSingleton instance = new Singleton();

private LoggerSingleton () {
}

public static LoggerSingleton getInstance() {
return instance ;
}
}

Ruby

or for sure the super simple in Ruby,

require 'singleton'
class LoggerSingleton
include Singleton
end

===Invoking Singletons===

The following coding is to invoke a singleton class in Java then in Ruby

Java

LoggerSingleton logger1 = LoggerSingleton.getInstance();
LoggerSingleton logger2 = LoggerSingleton.getInstance();
LoggerSingleton logger3 = new LoggerSingleton(); // compilation error will occur; The constructor is private.
System.out.println(logger1);
System.out.println(logger2);

Ruby

logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance

===Test Singletons===

The following coding is to test singleton class in Java then in Ruby

Java

import junit.framework.Assert;
import junit.framework.TestCase;
public class TestSingleton extends TestCase {
private LoggerSingleton logger1 = null, logger2 = null;
public TestSingleton(String name) {
super(name);
}
public void setUp() {
logger1 = LoggerSingleton.getInstance();
logger2 = LoggerSingleton.getInstance();
}
public void testUnique() {
System.out.println(logger1);
System.out.println(logger2);
Assert.assertEquals(true, logger1 == logger2);
}
}

Ruby

def testSingleton
logger1 = LoggerSingleton.instance
logger2 = LoggerSingleton.instance
assertEqual logger1, logger2
end

== Comparison ==
When comparing Singleton Pattern in Java and Ruby, it is shown that Ruby obviously is better than Java. It seems that Ruby would win because of the simplicity compared to Java since only one line of code "include Singleton" enables all the functionalities when Java needs more lines to do this. Since Ruby uses singleton mixins, it is easier to implemenet and since Java does not use mixins, it requires more implementation in the coding.

== Conclusion ==
Java doesn’t contain singleton pattern in the language itself, although implementation for the pattern is still possible. While in Ruby the singleton pattern is in the language itself, which became possible since Ruby is a dynamic language through singleton module.

== References ==
Head First Design Patterns by Eric Freeman, Kathy Sierra, Bert Bates, Elisabeth Freeman 
Programming Ruby: The Pragmatic Programmers' Guide (Pragmatic Programmers Series) by Dave Thomas, Andy Hunt, Andrew Hunt, Chad Fowler, Chad Fowler

=== External Links ===
[http://en.wikipedia.org/wiki/Singleton_pattern Singleton Pattern Wiki]