Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-13T01:26:34Z

Vsubram3: /* Observer Pattern */

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages. [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ 5] [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter 2]

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. [http://sourcemaking.com/design_patterns 1] 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. [http://c2.com/cgi/wiki?DesignPatterns 3] 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible. [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table 11] [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1e_az chapter1]

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here. [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf 4]

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://c2.com/cgi/wiki?ObserverPattern 6]

[[Image:Fig5_1.png]]

Fig 5.1 Use Case diagram for Observer pattern

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm 8]

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit. [http://www.oodesign.com/decorator-pattern.html 7]

[[Image:Fig6_1.png]]

Fig 6.1 Use Case diagram for Observer pattern

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns. [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html 9]

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions. [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ 10]

[[Image:Fig7_1.png]]

Fig 7.1 Use Case diagram for Iterator pattern

==Implementation of Iterator pattern in ruby==

===Example 1 square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

=References=
*[1]: [http://sourcemaking.com/design_patterns Design Patterns, Source Making]

*[2]: [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter Design pattern, computer_science wikipedia]

*[3]: [http://c2.com/cgi/wiki?DesignPatterns Design Patterns wiki]

*[4]: [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf irisa]

*[5]: [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ Slides, uottawa]

*[6]: [http://c2.com/cgi/wiki?ObserverPattern Observer Pattern, c2.com]

*[7]: [http://www.oodesign.com/decorator-pattern.html Decorator Pattern, oodesign]

*[8]: [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm Ruby Design Patterns, Observer Pattern, oreillynet]

*[9]: [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html Decorator Pattern with Ruby, lukeredpath]

*[10]: [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ Iterators in Ruby, devarticles]

*[11]: [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table uottawa]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-13T01:25:49Z

Vsubram3: /* Implementation of Decorator pattern in ruby */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T15:40:50Z

Vsubram3: /* Example square_arrayElements */

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages. [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ 5] [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter 2]

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. [http://sourcemaking.com/design_patterns 1] 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. [http://c2.com/cgi/wiki?DesignPatterns 3] 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible. [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table 11]

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here. [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf 4]

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://c2.com/cgi/wiki?ObserverPattern 6]

[[Image:Fig5_1.png]]

Fig 5.1 Use Case diagram for Observer pattern

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm 8]

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit. [http://www.oodesign.com/decorator-pattern.html 7]

[[Image:Fig6_1.png]]

Fig 6.1 Use Case diagram for Observer pattern

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns. [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html 9]

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions. [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ 10]

[[Image:Fig7_1.png]]

Fig 7.1 Use Case diagram for Iterator pattern

==Implementation of Iterator pattern in ruby==

===Example 1 square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

=References=
*[1]: [http://sourcemaking.com/design_patterns Design Patterns (Source Making)]

*[2]: [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter Design pattern (computer_science) wikipedia.org]

*[3]: [http://c2.com/cgi/wiki?DesignPatterns Design Patterns wiki]

*[4]: [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf irisa.fr]

*[5]: [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ Slides, uottawa.ca]

*[6]: [http://c2.com/cgi/wiki?ObserverPattern Observer Pattern, c2.com]

*[7]: [http://www.oodesign.com/decorator-pattern.html Decorator Pattern, oodesign.com]

*[8]: [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm Ruby Design Patterns, Observer Pattern, oreillynet.com]

*[9]: [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html Decorator Pattern with Ruby, lukeredpath.co.uk]

*[10]: [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ Iterators in Ruby, devarticles.com]

*[11]: [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table uottawa.ca]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T15:40:26Z

Vsubram3: /* Example - square_arrayElements */

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages. [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ 5] [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter 2]

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. [http://sourcemaking.com/design_patterns 1] 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. [http://c2.com/cgi/wiki?DesignPatterns 3] 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible. [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table 11]

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here. [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf 4]

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://c2.com/cgi/wiki?ObserverPattern 6]

[[Image:Fig5_1.png]]

Fig 5.1 Use Case diagram for Observer pattern

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm 8]

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit. [http://www.oodesign.com/decorator-pattern.html 7]

[[Image:Fig6_1.png]]

Fig 6.1 Use Case diagram for Observer pattern

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns. [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html 9]

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions. [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ 10]

[[Image:Fig7_1.png]]

Fig 7.1 Use Case diagram for Iterator pattern

==Implementation of Iterator pattern in ruby==

===Example square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

=References=
*[1]: [http://sourcemaking.com/design_patterns Design Patterns (Source Making)]

*[2]: [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter Design pattern (computer_science) wikipedia.org]

*[3]: [http://c2.com/cgi/wiki?DesignPatterns Design Patterns wiki]

*[4]: [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf irisa.fr]

*[5]: [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ Slides, uottawa.ca]

*[6]: [http://c2.com/cgi/wiki?ObserverPattern Observer Pattern, c2.com]

*[7]: [http://www.oodesign.com/decorator-pattern.html Decorator Pattern, oodesign.com]

*[8]: [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm Ruby Design Patterns, Observer Pattern, oreillynet.com]

*[9]: [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html Decorator Pattern with Ruby, lukeredpath.co.uk]

*[10]: [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ Iterators in Ruby, devarticles.com]

*[11]: [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table uottawa.ca]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T15:40:09Z

Vsubram3: /* Implementation of Iterator pattern in ruby */

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages. [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ 5] [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter 2]

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. [http://sourcemaking.com/design_patterns 1] 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. [http://c2.com/cgi/wiki?DesignPatterns 3] 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible. [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table 11]

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here. [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf 4]

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://c2.com/cgi/wiki?ObserverPattern 6]

[[Image:Fig5_1.png]]

Fig 5.1 Use Case diagram for Observer pattern

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm 8]

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit. [http://www.oodesign.com/decorator-pattern.html 7]

[[Image:Fig6_1.png]]

Fig 6.1 Use Case diagram for Observer pattern

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns. [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html 9]

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions. [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ 10]

[[Image:Fig7_1.png]]

Fig 7.1 Use Case diagram for Iterator pattern

==Implementation of Iterator pattern in ruby==

===Example - square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

=References=
*[1]: [http://sourcemaking.com/design_patterns Design Patterns (Source Making)]

*[2]: [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter Design pattern (computer_science) wikipedia.org]

*[3]: [http://c2.com/cgi/wiki?DesignPatterns Design Patterns wiki]

*[4]: [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf irisa.fr]

*[5]: [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ Slides, uottawa.ca]

*[6]: [http://c2.com/cgi/wiki?ObserverPattern Observer Pattern, c2.com]

*[7]: [http://www.oodesign.com/decorator-pattern.html Decorator Pattern, oodesign.com]

*[8]: [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm Ruby Design Patterns, Observer Pattern, oreillynet.com]

*[9]: [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html Decorator Pattern with Ruby, lukeredpath.co.uk]

*[10]: [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ Iterators in Ruby, devarticles.com]

*[11]: [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table uottawa.ca]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T07:59:43Z

Vsubram3: /* conclusion */

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages.

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible.

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here.

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit.

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns.

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions.

==Implementation of Iterator pattern in ruby==

===Example 1 - square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T07:48:05Z

Vsubram3: /* Example 2 EvenOrOdd */

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages.

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible.

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here.

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit.

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns.

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions.

==Implementation of Iterator pattern in ruby==

===Example 1 - square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above. The real-world situations where each design pattern can be used were illustrated with examples.

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T07:44:23Z

Vsubram3: /* Example 1 - square_arrayElements */

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages.

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible.

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here.

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit.

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns.

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions.

==Implementation of Iterator pattern in ruby==

===Example 1 - square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T07:41:02Z

Vsubram3: /* output */

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages.

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible.

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here.

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit.

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns.

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions.

==Implementation of Iterator pattern in ruby==

===Example 1 - square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T07:25:16Z

Vsubram3: /* output */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T07:24:56Z

Vsubram3: /* output */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T07:24:28Z

Vsubram3: /* Implementation of Decorator pattern in ruby */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T07:21:22Z

Vsubram3: /* Output: */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T07:13:29Z

Vsubram3: /* Implementation of observer pattern in ruby */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T07:11:48Z

Vsubram3: /* Implementation of observer pattern in ruby */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T07:04:31Z

Vsubram3: /* Observer Pattern */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T06:55:22Z

Vsubram3: /* Design patterns in dynamic programming languages */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T06:53:57Z

Vsubram3: /* Importance of design patterns in programming languages */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T06:53:15Z

Vsubram3: /* Importance of design patterns in programming languages */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T06:52:56Z

Vsubram3:

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T06:51:37Z

Vsubram3: /* How to choose a particular design pattern? */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T06:48:56Z

Vsubram3: /* Design Pattern */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T06:48:10Z

Vsubram3: /* How to choose a particular design pattern? */

=Novel implementations of design patterns in dynamic languages=

===Design Pattern===

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages.

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design.

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T06:47:43Z

Vsubram3: /* Importance of design patterns in programming languages */

=Novel implementations of design patterns in dynamic languages=

===Design Pattern===

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages.

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem.
ii. Recognize the different solutions that can be used to solve the problem.
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context.
iv. Recognize the language limitations for each of the design patterns.
v. Finally choose the most suitable and efficient design.

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T06:46:48Z

Vsubram3: /* Importance of design patterns in programming languages */

=Novel implementations of design patterns in dynamic languages=

===Design Pattern===

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages.

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem.
ii. Recognize the different solutions that can be used to solve the problem.
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context.
iv. Recognize the language limitations for each of the design patterns.
v. Finally choose the most suitable and efficient design.

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T06:43:35Z

Vsubram3:

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T05:51:09Z

Vsubram3: /* Novel implementations of design patterns in dynamic languages */

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T05:44:24Z

Vsubram3:

CSC/ECE 517 Fall 2010 ch5 5f aj

2010-11-02T16:05:55Z

Vsubram3:

CSC/ECE 517 Fall 2010/ch3 3b sv

2010-10-14T03:40:53Z

Vsubram3: /* Mixin */

= Multiple Inheritance and Mixins =

The concept of '''Inheritance''' and its working is explained in most of the [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] (OOP) overviews. But a very few of these OOP overviews discuss alternatives when Inheritance fails to be the best design choice for an OO application. The main focus of this topic is to introduce the case where Inheritance proves to be a bad design option and discuss the concepts which are practiced to overcome it. The discussion starts with brief description of what Inheritance is and how it works. The classic scenario of the '''deadly Diamond problem''' is mentioned to discuss why exactly inheritance is criticized. The potential alternatives to solve this problem are introduced. We look at the merits and demerits of these alternatives. This topic discusses [http://en.wikipedia.org/wiki/Mixin/ Mixins] more closely. 

=== Inheritance in OOP Design ===

'''Inheritance''' is a concept of OOP that facilitates reuse and compartmentalization of code by creating objects (which are collections of attributes and behaviors) that can be derived from existing objects. The deriving object (class) is termed as the ''child class/sub-class/derived class'', and, the object (class) whose methods are being used is called the ''parent class/super-class/base class''. This relationship between the super and sub-classes arising due to inheritance creates a hierarchy amongst the classes. Inheritance is termed as '' Single Inheritance'' if there is only one base class. Languages like C++,Java,Ruby,Python and SmallTalk support inheritance. 

Single inheritance creates a [http://en.wikipedia.org/wiki/Is-a/ Is-A] relationship amongst the classes. Consider the concept of single inheritance using class extension feature:

<pre>
class Animal{
//...
}

class Reptiles extends Animal{
//...
}

</pre>

In the above example, the Reptiles class is a '''specialization''' of Animals class and derives some/all of its attributes and/or methods from the Animal class.

The next section briefly discusses the alternatives of Inheritance used in various OO languages. 

=Definitions=

===Multiple Inheritance===

If a child class inherits behaviors and attributes from two or more parent classes, it is termed as ''Multiple Inheritance''. Languages supporting this feature include C++, Perl and Python. The main advantage of ''Multiple Inheritance'' is that it enables an user to combine independent (and not so independent) concepts (classes) into a composite concept called the derived class. For instance, given a set of ''interaction'' base classes and a set of base classes defining ''display options'', the user can create a new window by selecting a style of window interaction and appearance from the given base classes. 

Suppose there are '''N''' concepts, each of which can be combined with one of '''M''' other concepts, '''N+M''' classes are required to represent all the combined concepts. The situation with N = M = 1 is Single Inheritance. Examples with N>=2 and M>=2 are common and Multiple Inheritance plays an important role in such situations by avoiding replication. 

The following figure depicts the use of multiple inheritance: 

[[Image:UntitledMI.jpg|frame|upright|center|Figure 1. Multiple Inheritance]] 

A novel has a certain number of chapters, characters and other properties that can be thought as features of class STORY. It also has features of class BOOK like publisher, a price, a weight and an ISBN number. Thus, Class NOVEL should inherit from both. 

Following is the code snippet showing the above mentioned example: 

<pre>
class STORY{
//...
}

class BOOK{
//...
}

class NOVEL : public STORY, public BOOK{
//...
}
</pre>
 

===Interfaces===

Java designers cut the features of multiple inheritance and operator overloading from C++ to keep the language ''simple, object oriented and familiar''. '''Interfaces''' were introduced in Java to simulate multiple inheritance. Interfaces (defined using the keyword '''interface''') are [http://en.wikipedia.org/wiki/Abstract_type/ abstract type] containing only the method signatures and constant declarations. A class which implements an interface does so by implementing all its methods. Thus, interfaces act as templates. 

Here's the example showing how interfaces are used in Java:

<pre>

interface Bird
{
public void fly();
}

public class Eagle implements Bird
{
public void fly()
{
System.out.println(“Eagle flies”);
}

public static void main(String args[])
{
Bird bird = new Eagle();
bird.fly();
}
}

public class Duck implements Bird
{
public void fly()
{
System.out.println(“I cannot fly!!”);
}

public static void main(String args[])
{
Bird bird = new Duck();
bird.fly();
}
}
</pre>
 

In the above example, the interface Bird has a method fly(). The Eagle class and the Duck class implement this method in different ways. Since each class making use of the interface has to implement all the methods of the interface, the methods in the interface can be implemented in different ways by different classes.

===Modules===

A module is defined as a component which regroups similar things. Modules differ from classes as modules are just names to regroup things which we think are similar, whereas, classes consist of variables and methods describing the state and the behavior of an entity [1]. A module "protects" the names it contains. The primary benefits of using modules are:

* The code is more organized.
* The risk of name clashes is eliminated as modules provide '''namespace''' facility.
* Mixins can be implemented using modules.

Unlike classes, objects can neither be created nor sub-classed based on modules. Instead, the functionality of a particular module can be specified to be added to a particular class or object. 

Following is an example code snippet showing the use of Modules in Ruby: [7]

<pre>

module takes_courses (parameter)
def takes
puts "student #{parameter} takes course csc517"
end
end

class students
include takes_courses -----> makes the module methods accessible
def student_name( param )
puts "student_name = #{param}"
end
end

student = students.new
#In class
student.student_name 'john' #student name = John

# In Module
student.takes #student John takes course csc517

</pre>

In the above example,A module called takes_courses is defined. This module contains a method called takes which prints the name of the student who has taken the course csc517. The class called students includes the module takes_courses. A new student object is created. This object calls a method (student_name) defined in the class. The output would be "student_name = John ". The same student object is used to call the method takes in the module. This outputs "student John takes course csc 517".

===Mixin===

Mixins are one of the defining features of Ruby that are closely related to ''Duck typing''. Duck typing is a technique that allows usage of objects to respond to a certain set of method calls interchangeably. Mixins are a group of methods that are not yet attached to any class. They exist in a module, and are useful only when they are included in a class. Mixin thus behaves as an interface with implemented methods. 

Mixins cannot be instantiated, but, provide functionality to be inherited by a subclass. Ruby supports only single inheritance. So, mixins prove to be of great importance in Ruby as they simulate multiple inheritance capability in Ruby which allows classes to inherit functionalities from two or more mixins [2],[3],[4].

An Enumeration is a type of mixin module which can be used by all the classes. It does not depend on the language syntax. It is defined as “ an operation that is performed on elements of a set”.

Example of enumeration is:
[34, 56, 76, 96].each {|a| puts a}
Here, Each element in the array is printed.

Following is an example showing the use of mixins: [8]

<pre>

module Draw
def draw_shape(param)
puts "draw #{param}"
end
end

class ParentClass
def shape
puts "shape is circle"
end
end

class Circle < ParentClass
include Draw
end

f = Circle.new
f.shape
f.draw_shape "circle"

</pre>
In the above example, a subclass circle inherits the methods defined in the parent class.The class circle also includes the drawModule. It can access the methods in the module.A new circle object is created which can access the methods in parent_class as well as the methods defined in the module. The output would be i)shape is a circle ii) draw circle

===Traits===

A ''trait'' can be considered as a collection of methods which serves as a simple model for structured object oriented programs [5]. The main difference between mixins and traits lies in the way both are composed. Mixins are composed using only the inheritance operation, but, traits can include symmetric sum, aliasing and method exclusion. Trait is not an abstract type and implements methods. 

With [http://www.iam.unibe.ch/~scg/Research/Traits/ Traits], classes are organized in a single inheritance hierarchy. Traits are basically used to specify incremental differences in the behavior of sub- and super-classes. Traits are supported in programming languages like Fortress,Perl,SmallTalk and Joose framework for JavaScript. 

Traits can be considered as a combination of interfaces that are abstract and their implementation. Here's a Scala trait representing objects that can be compared and ordered: 

<pre>
trait Ord {
def < (that: Any): Boolean
def <=(that: Any): Boolean = (this < that) || (this == that)
def > (that: Any): Boolean = !(this <= that)
def >=(that: Any): Boolean = !(this < that)
}

class Date extends Ord {
def < (that: Any): Boolean = /* implementation */
}

// can now write myDate >= yourDate
</pre> 

As we can see in the above example, Date only needs to implement <. It gets the other operators for free. [9]

= Diamond Problem : Loophole in Multiple Inheritance =

With single inheritance, classes cannot be classified into the branches of the hierarchy and hence, is limiting. Multiple inheritance overcomes this and supports complex relationship models.

But multiple inheritance has the following problems: 

* It is possible that a class inherits multiple features with the same name.
* There can be more than one path to a given ancestor from a class (known as the ''diamond problem '' or ''fork-join'' inheritance) 
* Encapsulation of inheritance: Does a client or inheritor of a class depend on the inheritance structure of that class?
* Common ancestor duplication problem: Should common ancestor be duplicated or not?
* Duplicate parent operation invocation problem: How is this problem of Multiple inheriting from two classes that both invoke the same parent operation on a common ancestor can cause duplicate invocation of this parent operation dealt with?

The conflicting-features problem can be resolved by permitting renaming or by having a linear class hierarchy. The ''diamond problem'' is an ambiguity arising when two classes B and C inherit from class A, and both B and C are inherited by class D. If both classes B and C override the definition of a method inherited from A, then, when class D inherits this same method, conflict arises if D should use the method from B or C.

[[Image:Untitled123.jpg|frame|center|Figure 2. The diamond problem hierarchy]]

In '''C++''', Virtual inheritance was proposed as one solution for class D to inherit only one copy of A's methods. But object initialization is a problem when we have only one copy. Another consequence of diamond problem is that multiple inheritance interacts poorly with modular type-checking of [http://en.wikipedia.org/wiki/Multiple_dispatch/ multiple dispatch].

'''Java''' makes use of the concept of interfaces to simulate Multiple Inheritance and the responsibility of implementing the functions defined in the interfaces lies with the classes making use of the interface. Similarly '''Ruby''' uses the concept of mixins and '''SmallTalk''' and '''Perl''' use Traits. But each solution has its own pros and cons. 

=How mixins solve the Diamond Problem=

Ruby supports only single inheritance, i.e; a given class can inherit from only one parent class. But it is allowed to mixin many modules into a class. Moreover, modules are not permitted to inherit from other modules or classes. As these two conditions have to be always followed, there will be no "diamond" inheritance situation as every class is guaranteed to have a single parent class in case of inheritance. 

As mentioned above, modules can mixin modules. So the following situation (hierarchy) may arise:

<pre>
module P

module Q module R

class X

</pre>

This hierarchy resembles Diamond Problem. But Ruby's method look-up flow [10: http://phrogz.net/RubyLibs/RubyMethodLookupFlow] guarantees that mixin modules are searched before the parent class. Thus, the order of mixing in is significant in Ruby which guarantees that the module/class to be searched is unambiguous. Hence, the diamond problem is avoided.

Though mixins avoid diamond problem, they have a few disadvantages too. The following section does a comparison between the concepts, namely, Multiple Inheritance, Interfaces and Mixins, mentioned above. 

=Comparison =

== Mixins and Interfaces ==

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:25%"|FEATURE
!style="width:25%"|MIXINS
!style="width:25%"|JAVA INTERFACES
|-
|Maintainability
|In Ruby, modules have the implementation of the methods. So all the classes who “include” the module get the same method and its functionality. The definition of the method can change at run time.
|Java forces the classes using the interfaces to implement the methods defined in the interface. This might lead to code duplication if two classes have similar functionality. Secondly, changes have to be made at both places if the method changes in future.
|-
|Size of the Code
|The class/objects automatically get access to the methods of the included module(s).
|If a class inherits multiple interfaces, it is forced to implement unnecessary, and sometimes, duplicate code which makes the code grow in size.
|-
|Readability
|The module and the class using the module can be in different files. Hence, the code is less readable. So mixins are beneficial for individual or small teams. For bigger teams, documentation becomes an important criterion.
|The code is more readable and explicit as the implementation of a method can be found at a place.
|-
|Naming Conflicts
|Modules provide the facility of namespace. So it is possible for a class to inherit two or more methods of same name from different modules.
|Since the class itself has to provide the implementation of the methods, inheriting methods of same names from different interfaces will signal an error message.
|-

|}

== Mixins and C++ Multiple Inheritance ==

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:15%"|
!style="width:25%"|ADVANTAGES
!style="width:25%"|DISADVANTAGES
|-
|MIXINS
|1. Avoids complex features like virtual base classes. 2. Code is less verbose. 3. Modules can be made aware of who included them.
|1. In case of naming conflicts while mixing multiple modules, notification of the error may be incorrect. 2. Ruby is used for implementation inheritance and finds very less use in inheritance implementation. 3. Since it supports non-virtual classes, getting two copies of the base class requires odd code.
|-
|C++ MULTIPLE INHERITANCE
|1. Naming conflicts point to the proper error normally. 2. Can be used for both interface and implementation inheritance. 3. Supports virtual base classes.
|1. C++ classes do not have any knowledge of who inherited them. 2. Poses diamond problem
|-

|}
 
 
In the classic scenario of diamond problem [ Figure 1 ], Ruby simplifies the inheritance to look like D<C<B<A. In C++ Multiple Inheritance, C::foo cannot call B::foo, but with Ruby mix-ins,this is possible. 

= Conclusion =

As we saw, each of the above approaches- Multiple Inheritance, Interfaces, Mixins and Traits - have their own pros and cons. Each one tries to solve the deadly ''Diamond problem'' in a different way, but, no one solves it completely. Traits have the disadvantage that they do not allow states. Different languages try to deal with this problem in a different way. JavaFX technology has introduced mixins too. 

As mentioned in the Sun Microsystem website [[http://java.sun.com/developer/technicalArticles/javafx/mixin/]], ''developers have a new style of class inheritance: a mixin. A mixin is a type of class that can be inherited by a subclass, but it is not meant for instantiation. In this manner, mixins are similar to interfaces in the Java programming language. However, the difference is that mixins may actually define method bodies and class variables in addition to constants and method signatures.'' 

Thus, we can conclude that it is the responsibility of the programmer to make the choice of which mechanism fits the best depending upon the task under consideration.

= References =

[1] http://ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html

[2] http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[3] http://ruby.about.com/od/beginningruby/a/mixin.htm

[4] http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful

[5] http://en.wikipedia.org/wiki/Trait_%28computer_science%29

[6] http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide

[7] http://codeshooter.wordpress.com/2008/09/27/including-and-extending-modules-in-ruby/

[8] http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/

[9] http://hestia.typepad.com/flatlander/2009/01/scala-for-c-programmers-part-1-mixins-and-traits.html

= See Also =

[1] http://www.oreillynet.com/ruby/blog/2007/01/digging_deep_mixing_it_up_or_i_1.html Article from O'Reilly's website which discusses mixins at depth

[2] http://www.sapphiresteel.com/The-Little-Book-Of-Ruby

[3] http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8

[4] http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[5] http://scg.unibe.ch/archive/projects/Reic05a.pdf

[6] http://scg.unibe.ch/archive/phd/schaerli-phd.pdf

CSC/ECE 517 Fall 2010/ch3 3b sv

2010-10-14T03:39:14Z

Vsubram3: /* Mixin */

= Multiple Inheritance and Mixins =

The concept of '''Inheritance''' and its working is explained in most of the [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] (OOP) overviews. But a very few of these OOP overviews discuss alternatives when Inheritance fails to be the best design choice for an OO application. The main focus of this topic is to introduce the case where Inheritance proves to be a bad design option and discuss the concepts which are practiced to overcome it. The discussion starts with brief description of what Inheritance is and how it works. The classic scenario of the '''deadly Diamond problem''' is mentioned to discuss why exactly inheritance is criticized. The potential alternatives to solve this problem are introduced. We look at the merits and demerits of these alternatives. This topic discusses [http://en.wikipedia.org/wiki/Mixin/ Mixins] more closely. 

=== Inheritance in OOP Design ===

'''Inheritance''' is a concept of OOP that facilitates reuse and compartmentalization of code by creating objects (which are collections of attributes and behaviors) that can be derived from existing objects. The deriving object (class) is termed as the ''child class/sub-class/derived class'', and, the object (class) whose methods are being used is called the ''parent class/super-class/base class''. This relationship between the super and sub-classes arising due to inheritance creates a hierarchy amongst the classes. Inheritance is termed as '' Single Inheritance'' if there is only one base class. Languages like C++,Java,Ruby,Python and SmallTalk support inheritance. 

Single inheritance creates a [http://en.wikipedia.org/wiki/Is-a/ Is-A] relationship amongst the classes. Consider the concept of single inheritance using class extension feature:

<pre>
class Animal{
//...
}

class Reptiles extends Animal{
//...
}

</pre>

In the above example, the Reptiles class is a '''specialization''' of Animals class and derives some/all of its attributes and/or methods from the Animal class.

The next section briefly discusses the alternatives of Inheritance used in various OO languages. 

=Definitions=

===Multiple Inheritance===

If a child class inherits behaviors and attributes from two or more parent classes, it is termed as ''Multiple Inheritance''. Languages supporting this feature include C++, Perl and Python. The main advantage of ''Multiple Inheritance'' is that it enables an user to combine independent (and not so independent) concepts (classes) into a composite concept called the derived class. For instance, given a set of ''interaction'' base classes and a set of base classes defining ''display options'', the user can create a new window by selecting a style of window interaction and appearance from the given base classes. 

Suppose there are '''N''' concepts, each of which can be combined with one of '''M''' other concepts, '''N+M''' classes are required to represent all the combined concepts. The situation with N = M = 1 is Single Inheritance. Examples with N>=2 and M>=2 are common and Multiple Inheritance plays an important role in such situations by avoiding replication. 

The following figure depicts the use of multiple inheritance: 

[[Image:UntitledMI.jpg|frame|upright|center|Figure 1. Multiple Inheritance]] 

A novel has a certain number of chapters, characters and other properties that can be thought as features of class STORY. It also has features of class BOOK like publisher, a price, a weight and an ISBN number. Thus, Class NOVEL should inherit from both. 

Following is the code snippet showing the above mentioned example: 

<pre>
class STORY{
//...
}

class BOOK{
//...
}

class NOVEL : public STORY, public BOOK{
//...
}
</pre>
 

===Interfaces===

Java designers cut the features of multiple inheritance and operator overloading from C++ to keep the language ''simple, object oriented and familiar''. '''Interfaces''' were introduced in Java to simulate multiple inheritance. Interfaces (defined using the keyword '''interface''') are [http://en.wikipedia.org/wiki/Abstract_type/ abstract type] containing only the method signatures and constant declarations. A class which implements an interface does so by implementing all its methods. Thus, interfaces act as templates. 

Here's the example showing how interfaces are used in Java:

<pre>

interface Bird
{
public void fly();
}

public class Eagle implements Bird
{
public void fly()
{
System.out.println(“Eagle flies”);
}

public static void main(String args[])
{
Bird bird = new Eagle();
bird.fly();
}
}

public class Duck implements Bird
{
public void fly()
{
System.out.println(“I cannot fly!!”);
}

public static void main(String args[])
{
Bird bird = new Duck();
bird.fly();
}
}
</pre>
 

In the above example, the interface Bird has a method fly(). The Eagle class and the Duck class implement this method in different ways. Since each class making use of the interface has to implement all the methods of the interface, the methods in the interface can be implemented in different ways by different classes.

===Modules===

A module is defined as a component which regroups similar things. Modules differ from classes as modules are just names to regroup things which we think are similar, whereas, classes consist of variables and methods describing the state and the behavior of an entity [1]. A module "protects" the names it contains. The primary benefits of using modules are:

* The code is more organized.
* The risk of name clashes is eliminated as modules provide '''namespace''' facility.
* Mixins can be implemented using modules.

Unlike classes, objects can neither be created nor sub-classed based on modules. Instead, the functionality of a particular module can be specified to be added to a particular class or object. 

Following is an example code snippet showing the use of Modules in Ruby: [7]

<pre>

module takes_courses (parameter)
def takes
puts "student #{parameter} takes course csc517"
end
end

class students
include takes_courses -----> makes the module methods accessible
def student_name( param )
puts "student_name = #{param}"
end
end

student = students.new
#In class
student.student_name 'john' #student name = John

# In Module
student.takes #student John takes course csc517

</pre>

In the above example,A module called takes_courses is defined. This module contains a method called takes which prints the name of the student who has taken the course csc517. The class called students includes the module takes_courses. A new student object is created. This object calls a method (student_name) defined in the class. The output would be "student_name = John ". The same student object is used to call the method takes in the module. This outputs "student John takes course csc 517".

===Mixin===

Mixins are one of the defining features of Ruby that are closely related to ''Duck typing''. Duck typing is a technique that allows usage of objects to respond to a certain set of method calls interchangeably. Mixins are a group of methods that are not yet attached to any class. They exist in a module, and are useful only when they are included in a class. Mixin thus behaves as an interface with implemented methods. 

Mixins cannot be instantiated, but, provide functionality to be inherited by a subclass. Ruby supports only single inheritance. So, mixins prove to be of great importance in Ruby as they simulate multiple inheritance capability in Ruby which allows classes to inherit functionalities from two or more mixins [2],[3],[4].

An Enumeration is a type of mixin module which can be used by all the classes. It does not depend on the language syntax. It is defined as “ an operation that is performed on elements of a set”.

Example of enumeration is:
[34, 56, 76, 96].each {|a| puts a}
Here, Each element in the array is printed.

Following is an example showing the use of mixins: [8]

<pre>

module Draw
def draw_shape
puts "draw "
end
end

class ParentClass
def shape
puts "shape is circle"
end
end

class Circle < ParentClass
include Draw
end

f = Circle.new
f.shape
f.draw_shape

</pre>
In the above example, a subclass circle inherits the methods defined in the parent class.The class circle also includes the drawModule. It can access the methods in the module.A new circle object is created which can access the methods in parent_class as well as the methods defined in the module. The output would be i)shape is a circle ii) draw

===Traits===

A ''trait'' can be considered as a collection of methods which serves as a simple model for structured object oriented programs [5]. The main difference between mixins and traits lies in the way both are composed. Mixins are composed using only the inheritance operation, but, traits can include symmetric sum, aliasing and method exclusion. Trait is not an abstract type and implements methods. 

With [http://www.iam.unibe.ch/~scg/Research/Traits/ Traits], classes are organized in a single inheritance hierarchy. Traits are basically used to specify incremental differences in the behavior of sub- and super-classes. Traits are supported in programming languages like Fortress,Perl,SmallTalk and Joose framework for JavaScript. 

Traits can be considered as a combination of interfaces that are abstract and their implementation. Here's a Scala trait representing objects that can be compared and ordered: 

<pre>
trait Ord {
def < (that: Any): Boolean
def <=(that: Any): Boolean = (this < that) || (this == that)
def > (that: Any): Boolean = !(this <= that)
def >=(that: Any): Boolean = !(this < that)
}

class Date extends Ord {
def < (that: Any): Boolean = /* implementation */
}

// can now write myDate >= yourDate
</pre> 

As we can see in the above example, Date only needs to implement <. It gets the other operators for free. [9]

= Diamond Problem : Loophole in Multiple Inheritance =

With single inheritance, classes cannot be classified into the branches of the hierarchy and hence, is limiting. Multiple inheritance overcomes this and supports complex relationship models.

But multiple inheritance has the following problems: 

* It is possible that a class inherits multiple features with the same name.
* There can be more than one path to a given ancestor from a class (known as the ''diamond problem '' or ''fork-join'' inheritance) 
* Encapsulation of inheritance: Does a client or inheritor of a class depend on the inheritance structure of that class?
* Common ancestor duplication problem: Should common ancestor be duplicated or not?
* Duplicate parent operation invocation problem: How is this problem of Multiple inheriting from two classes that both invoke the same parent operation on a common ancestor can cause duplicate invocation of this parent operation dealt with?

The conflicting-features problem can be resolved by permitting renaming or by having a linear class hierarchy. The ''diamond problem'' is an ambiguity arising when two classes B and C inherit from class A, and both B and C are inherited by class D. If both classes B and C override the definition of a method inherited from A, then, when class D inherits this same method, conflict arises if D should use the method from B or C.

[[Image:Untitled123.jpg|frame|center|Figure 2. The diamond problem hierarchy]]

In '''C++''', Virtual inheritance was proposed as one solution for class D to inherit only one copy of A's methods. But object initialization is a problem when we have only one copy. Another consequence of diamond problem is that multiple inheritance interacts poorly with modular type-checking of [http://en.wikipedia.org/wiki/Multiple_dispatch/ multiple dispatch].

'''Java''' makes use of the concept of interfaces to simulate Multiple Inheritance and the responsibility of implementing the functions defined in the interfaces lies with the classes making use of the interface. Similarly '''Ruby''' uses the concept of mixins and '''SmallTalk''' and '''Perl''' use Traits. But each solution has its own pros and cons. 

=How mixins solve the Diamond Problem=

Ruby supports only single inheritance, i.e; a given class can inherit from only one parent class. But it is allowed to mixin many modules into a class. Moreover, modules are not permitted to inherit from other modules or classes. As these two conditions have to be always followed, there will be no "diamond" inheritance situation as every class is guaranteed to have a single parent class in case of inheritance. 

As mentioned above, modules can mixin modules. So the following situation (hierarchy) may arise:

<pre>
module P

module Q module R

class X

</pre>

This hierarchy resembles Diamond Problem. But Ruby's method look-up flow [10: http://phrogz.net/RubyLibs/RubyMethodLookupFlow] guarantees that mixin modules are searched before the parent class. Thus, the order of mixing in is significant in Ruby which guarantees that the module/class to be searched is unambiguous. Hence, the diamond problem is avoided.

Though mixins avoid diamond problem, they have a few disadvantages too. The following section does a comparison between the concepts, namely, Multiple Inheritance, Interfaces and Mixins, mentioned above. 

=Comparison =

== Mixins and Interfaces ==

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:25%"|FEATURE
!style="width:25%"|MIXINS
!style="width:25%"|JAVA INTERFACES
|-
|Maintainability
|In Ruby, modules have the implementation of the methods. So all the classes who “include” the module get the same method and its functionality. The definition of the method can change at run time.
|Java forces the classes using the interfaces to implement the methods defined in the interface. This might lead to code duplication if two classes have similar functionality. Secondly, changes have to be made at both places if the method changes in future.
|-
|Size of the Code
|The class/objects automatically get access to the methods of the included module(s).
|If a class inherits multiple interfaces, it is forced to implement unnecessary, and sometimes, duplicate code which makes the code grow in size.
|-
|Readability
|The module and the class using the module can be in different files. Hence, the code is less readable. So mixins are beneficial for individual or small teams. For bigger teams, documentation becomes an important criterion.
|The code is more readable and explicit as the implementation of a method can be found at a place.
|-
|Naming Conflicts
|Modules provide the facility of namespace. So it is possible for a class to inherit two or more methods of same name from different modules.
|Since the class itself has to provide the implementation of the methods, inheriting methods of same names from different interfaces will signal an error message.
|-

|}

== Mixins and C++ Multiple Inheritance ==

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:15%"|
!style="width:25%"|ADVANTAGES
!style="width:25%"|DISADVANTAGES
|-
|MIXINS
|1. Avoids complex features like virtual base classes. 2. Code is less verbose. 3. Modules can be made aware of who included them.
|1. In case of naming conflicts while mixing multiple modules, notification of the error may be incorrect. 2. Ruby is used for implementation inheritance and finds very less use in inheritance implementation. 3. Since it supports non-virtual classes, getting two copies of the base class requires odd code.
|-
|C++ MULTIPLE INHERITANCE
|1. Naming conflicts point to the proper error normally. 2. Can be used for both interface and implementation inheritance. 3. Supports virtual base classes.
|1. C++ classes do not have any knowledge of who inherited them. 2. Poses diamond problem
|-

|}
 
 
In the classic scenario of diamond problem [ Figure 1 ], Ruby simplifies the inheritance to look like D<C<B<A. In C++ Multiple Inheritance, C::foo cannot call B::foo, but with Ruby mix-ins,this is possible. 

= Conclusion =

As we saw, each of the above approaches- Multiple Inheritance, Interfaces, Mixins and Traits - have their own pros and cons. Each one tries to solve the deadly ''Diamond problem'' in a different way, but, no one solves it completely. Traits have the disadvantage that they do not allow states. Different languages try to deal with this problem in a different way. JavaFX technology has introduced mixins too. 

As mentioned in the Sun Microsystem website [[http://java.sun.com/developer/technicalArticles/javafx/mixin/]], ''developers have a new style of class inheritance: a mixin. A mixin is a type of class that can be inherited by a subclass, but it is not meant for instantiation. In this manner, mixins are similar to interfaces in the Java programming language. However, the difference is that mixins may actually define method bodies and class variables in addition to constants and method signatures.'' 

Thus, we can conclude that it is the responsibility of the programmer to make the choice of which mechanism fits the best depending upon the task under consideration.

= References =

[1] http://ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html

[2] http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[3] http://ruby.about.com/od/beginningruby/a/mixin.htm

[4] http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful

[5] http://en.wikipedia.org/wiki/Trait_%28computer_science%29

[6] http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide

[7] http://codeshooter.wordpress.com/2008/09/27/including-and-extending-modules-in-ruby/

[8] http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/

[9] http://hestia.typepad.com/flatlander/2009/01/scala-for-c-programmers-part-1-mixins-and-traits.html

= See Also =

[1] http://www.oreillynet.com/ruby/blog/2007/01/digging_deep_mixing_it_up_or_i_1.html Article from O'Reilly's website which discusses mixins at depth

[2] http://www.sapphiresteel.com/The-Little-Book-Of-Ruby

[3] http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8

[4] http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[5] http://scg.unibe.ch/archive/projects/Reic05a.pdf

[6] http://scg.unibe.ch/archive/phd/schaerli-phd.pdf

CSC/ECE 517 Fall 2010/ch3 3b sv

2010-10-14T03:14:02Z

Vsubram3: /* Mixin */

= Multiple Inheritance and Mixins =

The concept of '''Inheritance''' and its working is explained in most of the [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] (OOP) overviews. But a very few of these OOP overviews discuss alternatives when Inheritance fails to be the best design choice for an OO application. The main focus of this topic is to introduce the case where Inheritance proves to be a bad design option and discuss the concepts which are practiced to overcome it. The discussion starts with brief description of what Inheritance is and how it works. The classic scenario of the '''deadly Diamond problem''' is mentioned to discuss why exactly inheritance is criticized. The potential alternatives to solve this problem are introduced. We look at the merits and demerits of these alternatives. This topic discusses [http://en.wikipedia.org/wiki/Mixin/ Mixins] more closely. 

=== Inheritance in OOP Design ===

'''Inheritance''' is a concept of OOP that facilitates reuse and compartmentalization of code by creating objects (which are collections of attributes and behaviors) that can be derived from existing objects. The deriving object (class) is termed as the ''child class/sub-class/derived class'', and, the object (class) whose methods are being used is called the ''parent class/super-class/base class''. This relationship between the super and sub-classes arising due to inheritance creates a hierarchy amongst the classes. Inheritance is termed as '' Single Inheritance'' if there is only one base class. Languages like C++,Java,Ruby,Python and SmallTalk support inheritance. 

Single inheritance creates a [http://en.wikipedia.org/wiki/Is-a/ Is-A] relationship amongst the classes. Consider the concept of single inheritance using class extension feature:

<pre>
class Animal{
//...
}

class Reptiles extends Animal{
//...
}

</pre>

In the above example, the Reptiles class is a '''specialization''' of Animals class and derives some/all of its attributes and/or methods from the Animal class.

The next section briefly discusses the alternatives of Inheritance used in various OO languages. 

=Definitions=

===Multiple Inheritance===

If a child class inherits behaviors and attributes from two or more parent classes, it is termed as ''Multiple Inheritance''. Languages supporting this feature include C++, Perl and Python. The main advantage of ''Multiple Inheritance'' is that it enables an user to combine independent (and not so independent) concepts (classes) into a composite concept called the derived class. For instance, given a set of ''interaction'' base classes and a set of base classes defining ''display options'', the user can create a new window by selecting a style of window interaction and appearance from the given base classes. 

Suppose there are '''N''' concepts, each of which can be combined with one of '''M''' other concepts, '''N+M''' classes are required to represent all the combined concepts. The situation with N = M = 1 is Single Inheritance. Examples with N>=2 and M>=2 are common and Multiple Inheritance plays an important role in such situations by avoiding replication. 

The following figure depicts the use of multiple inheritance: 

[[Image:UntitledMI.jpg|frame|upright|center|Figure 1. Multiple Inheritance]] 

A novel has a certain number of chapters, characters and other properties that can be thought as features of class STORY. It also has features of class BOOK like publisher, a price, a weight and an ISBN number. Thus, Class NOVEL should inherit from both. 

Following is the code snippet showing the above mentioned example: 

<pre>
class STORY{
//...
}

class BOOK{
//...
}

class NOVEL : public STORY, public BOOK{
//...
}
</pre>
 

===Interfaces===

Java designers cut the features of multiple inheritance and operator overloading from C++ to keep the language ''simple, object oriented and familiar''. '''Interfaces''' were introduced in Java to simulate multiple inheritance. Interfaces (defined using the keyword '''interface''') are [http://en.wikipedia.org/wiki/Abstract_type/ abstract type] containing only the method signatures and constant declarations. A class which implements an interface does so by implementing all its methods. Thus, interfaces act as templates. 

Here's the example showing how interfaces are used in Java:

<pre>

interface Bird
{
public void fly();
}

public class Eagle implements Bird
{
public void fly()
{
System.out.println(“Eagle flies”);
}

public static void main(String args[])
{
Bird bird = new Eagle();
bird.fly();
}
}

public class Duck implements Bird
{
public void fly()
{
System.out.println(“I cannot fly!!”);
}

public static void main(String args[])
{
Bird bird = new Duck();
bird.fly();
}
}
</pre>
 

In the above example, the interface Bird has a method fly(). The Eagle class and the Duck class implement this method in different ways. Since each class making use of the interface has to implement all the methods of the interface, the methods in the interface can be implemented in different ways by different classes.

===Modules===

A module is defined as a component which regroups similar things. Modules differ from classes as modules are just names to regroup things which we think are similar, whereas, classes consist of variables and methods describing the state and the behavior of an entity [1]. A module "protects" the names it contains. The primary benefits of using modules are:

* The code is more organized.
* The risk of name clashes is eliminated as modules provide '''namespace''' facility.
* Mixins can be implemented using modules.

Unlike classes, objects can neither be created nor sub-classed based on modules. Instead, the functionality of a particular module can be specified to be added to a particular class or object. 

Following is an example code snippet showing the use of Modules in Ruby: [7]

<pre>

module takes_courses (parameter)
def takes
puts "student #{parameter} takes course csc517"
end
end

class students
include takes_courses -----> makes the module methods accessible
def student_name( param )
puts "student_name = #{param}"
end
end

student = students.new
#In class
student.student_name 'john' #student name = John

# In Module
student.takes #student John takes course csc517

</pre>

In the above example,A module called takes_courses is defined. This module contains a method called takes which prints the name of the student who has taken the course csc517. The class called students includes the module takes_courses. A new student object is created. This object calls a method (student_name) defined in the class. The output would be "student_name = John ". The same student object is used to call the method takes in the module. This outputs "student John takes course csc 517".

===Mixin===

Mixins are one of the defining features of Ruby that are closely related to ''Duck typing''. Duck typing is a technique that allows usage of objects to respond to a certain set of method calls interchangeably. Mixins are a group of methods that are not yet attached to any class. They exist in a module, and are useful only when they are included in a class. Mixin thus behaves as an interface with implemented methods. 

Mixins cannot be instantiated, but, provide functionality to be inherited by a subclass. Ruby supports only single inheritance. So, mixins prove to be of great importance in Ruby as they simulate multiple inheritance capability in Ruby which allows classes to inherit functionalities from two or more mixins [2],[3],[4].

An Enumeration is a type of mixin module which can be used by all the classes. It does not depend on the language syntax. It is defined as “ an operation that is performed on elements of a set”.

Example of enumeration is:
[34, 56, 76, 96].each {|a| puts a}
Here, Each element in the array is printed.

Following is an example showing the use of mixins: [8]

<pre>

module drawModule
def draw_shape
puts ”draw”
end
end

class parentClass
def shape
puts “shape is circle”
end
end

class circle < parentClass
include drawModule
end

f = circle.new
f.parentClass
f.draw_shape

</pre>
In the above example, a subclass circle inherits the methods defined in the parent class.The class circle also includes the drawModule. It can access the methods in the module.A new circle object is created which can access the methods in parent_class as well as the methods defined in the module

===Traits===

A ''trait'' can be considered as a collection of methods which serves as a simple model for structured object oriented programs [5]. The main difference between mixins and traits lies in the way both are composed. Mixins are composed using only the inheritance operation, but, traits can include symmetric sum, aliasing and method exclusion. Trait is not an abstract type and implements methods. 

With [http://www.iam.unibe.ch/~scg/Research/Traits/ Traits], classes are organized in a single inheritance hierarchy. Traits are basically used to specify incremental differences in the behavior of sub- and super-classes. Traits are supported in programming languages like Fortress,Perl,SmallTalk and Joose framework for JavaScript. 

Traits can be considered as a combination of interfaces that are abstract and their implementation. Here's a Scala trait representing objects that can be compared and ordered: 

<pre>
trait Ord {
def < (that: Any): Boolean
def <=(that: Any): Boolean = (this < that) || (this == that)
def > (that: Any): Boolean = !(this <= that)
def >=(that: Any): Boolean = !(this < that)
}

class Date extends Ord {
def < (that: Any): Boolean = /* implementation */
}

// can now write myDate >= yourDate
</pre> 

As we can see in the above example, Date only needs to implement <. It gets the other operators for free. [9]

= Diamond Problem : Loophole in Multiple Inheritance =

With single inheritance, classes cannot be classified into the branches of the hierarchy and hence, is limiting. Multiple inheritance overcomes this and supports complex relationship models.

But multiple inheritance has the following problems: 

* It is possible that a class inherits multiple features with the same name.
* There can be more than one path to a given ancestor from a class (known as the ''diamond problem '' or ''fork-join'' inheritance) 
* Encapsulation of inheritance: Does a client or inheritor of a class depend on the inheritance structure of that class?
* Common ancestor duplication problem: Should common ancestor be duplicated or not?
* Duplicate parent operation invocation problem: How is this problem of Multiple inheriting from two classes that both invoke the same parent operation on a common ancestor can cause duplicate invocation of this parent operation dealt with?

The conflicting-features problem can be resolved by permitting renaming or by having a linear class hierarchy. The ''diamond problem'' is an ambiguity arising when two classes B and C inherit from class A, and both B and C are inherited by class D. If both classes B and C override the definition of a method inherited from A, then, when class D inherits this same method, conflict arises if D should use the method from B or C.

[[Image:Untitled123.jpg|frame|center|Figure 2. The diamond problem hierarchy]]

In '''C++''', Virtual inheritance was proposed as one solution for class D to inherit only one copy of A's methods. But object initialization is a problem when we have only one copy. Another consequence of diamond problem is that multiple inheritance interacts poorly with modular type-checking of [http://en.wikipedia.org/wiki/Multiple_dispatch/ multiple dispatch].

'''Java''' makes use of the concept of interfaces to simulate Multiple Inheritance and the responsibility of implementing the functions defined in the interfaces lies with the classes making use of the interface. Similarly '''Ruby''' uses the concept of mixins and '''SmallTalk''' and '''Perl''' use Traits. But each solution has its own pros and cons. 

=How mixins solve the Diamond Problem=

Ruby supports only single inheritance, i.e; a given class can inherit from only one parent class. But it is allowed to mixin many modules into a class. Moreover, modules are not permitted to inherit from other modules or classes. As these two conditions have to be always followed, there will be no "diamond" inheritance situation as every class is guaranteed to have a single parent class in case of inheritance. 

As mentioned above, modules can mixin modules. So the following situation (hierarchy) may arise:

<pre>
module P

module Q module R

class X

</pre>

This hierarchy resembles Diamond Problem. But Ruby's method look-up flow [10: http://phrogz.net/RubyLibs/RubyMethodLookupFlow] guarantees that mixin modules are searched before the parent class. Thus, the order of mixing in is significant in Ruby which guarantees that the module/class to be searched is unambiguous. Hence, the diamond problem is avoided.

Though mixins avoid diamond problem, they have a few disadvantages too. The following section does a comparison between the concepts, namely, Multiple Inheritance, Interfaces and Mixins, mentioned above. 

=Comparison =

== Mixins and Interfaces ==

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:25%"|FEATURE
!style="width:25%"|MIXINS
!style="width:25%"|JAVA INTERFACES
|-
|Maintainability
|In Ruby, modules have the implementation of the methods. So all the classes who “include” the module get the same method and its functionality. The definition of the method can change at run time.
|Java forces the classes using the interfaces to implement the methods defined in the interface. This might lead to code duplication if two classes have similar functionality. Secondly, changes have to be made at both places if the method changes in future.
|-
|Size of the Code
|The class/objects automatically get access to the methods of the included module(s).
|If a class inherits multiple interfaces, it is forced to implement unnecessary, and sometimes, duplicate code which makes the code grow in size.
|-
|Readability
|The module and the class using the module can be in different files. Hence, the code is less readable. So mixins are beneficial for individual or small teams. For bigger teams, documentation becomes an important criterion.
|The code is more readable and explicit as the implementation of a method can be found at a place.
|-
|Naming Conflicts
|Modules provide the facility of namespace. So it is possible for a class to inherit two or more methods of same name from different modules.
|Since the class itself has to provide the implementation of the methods, inheriting methods of same names from different interfaces will signal an error message.
|-

|}

== Mixins and C++ Multiple Inheritance ==

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:15%"|
!style="width:25%"|ADVANTAGES
!style="width:25%"|DISADVANTAGES
|-
|MIXINS
|1. Avoids complex features like virtual base classes. 2. Code is less verbose. 3. Modules can be made aware of who included them.
|1. In case of naming conflicts while mixing multiple modules, notification of the error may be incorrect. 2. Ruby is used for implementation inheritance and finds very less use in inheritance implementation. 3. Since it supports non-virtual classes, getting two copies of the base class requires odd code.
|-
|C++ MULTIPLE INHERITANCE
|1. Naming conflicts point to the proper error normally. 2. Can be used for both interface and implementation inheritance. 3. Supports virtual base classes.
|1. C++ classes do not have any knowledge of who inherited them. 2. Poses diamond problem
|-

|}
 
 
In the classic scenario of diamond problem [ Figure 1 ], Ruby simplifies the inheritance to look like D<C<B<A. In C++ Multiple Inheritance, C::foo cannot call B::foo, but with Ruby mix-ins,this is possible. 

= Conclusion =

As we saw, each of the above approaches- Multiple Inheritance, Interfaces, Mixins and Traits - have their own pros and cons. Each one tries to solve the deadly ''Diamond problem'' in a different way, but, no one solves it completely. Traits have the disadvantage that they do not allow states. Different languages try to deal with this problem in a different way. JavaFX technology has introduced mixins too. 

As mentioned in the Sun Microsystem website [[http://java.sun.com/developer/technicalArticles/javafx/mixin/]], ''developers have a new style of class inheritance: a mixin. A mixin is a type of class that can be inherited by a subclass, but it is not meant for instantiation. In this manner, mixins are similar to interfaces in the Java programming language. However, the difference is that mixins may actually define method bodies and class variables in addition to constants and method signatures.'' 

Thus, we can conclude that it is the responsibility of the programmer to make the choice of which mechanism fits the best depending upon the task under consideration.

= References =

[1] http://ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html

[2] http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[3] http://ruby.about.com/od/beginningruby/a/mixin.htm

[4] http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful

[5] http://en.wikipedia.org/wiki/Trait_%28computer_science%29

[6] http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide

[7] http://codeshooter.wordpress.com/2008/09/27/including-and-extending-modules-in-ruby/

[8] http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/

[9] http://hestia.typepad.com/flatlander/2009/01/scala-for-c-programmers-part-1-mixins-and-traits.html

= See Also =

[1] http://www.oreillynet.com/ruby/blog/2007/01/digging_deep_mixing_it_up_or_i_1.html Article from O'Reilly's website which discusses mixins at depth

[2] http://www.sapphiresteel.com/The-Little-Book-Of-Ruby

[3] http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8

[4] http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[5] http://scg.unibe.ch/archive/projects/Reic05a.pdf

[6] http://scg.unibe.ch/archive/phd/schaerli-phd.pdf

CSC/ECE 517 Fall 2010/ch3 3b sv

2010-10-14T02:00:30Z

Vsubram3: /* Modules */

= Multiple Inheritance and Mixins =

The concept of '''Inheritance''' and its working is explained in most of the [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] (OOP) overviews. But a very few of these OOP overviews discuss alternatives when Inheritance fails to be the best design choice for an OO application. The main focus of this topic is to introduce the case where Inheritance proves to be a bad design option and discuss the concepts which are practiced to overcome it. The discussion starts with brief description of what Inheritance is and how it works. The classic scenario of the '''deadly Diamond problem''' is mentioned to discuss why exactly inheritance is criticized. The potential alternatives to solve this problem are introduced. We look at the merits and demerits of these alternatives. This topic discusses [http://en.wikipedia.org/wiki/Mixin/ Mixins] more closely. 

=== Inheritance in OOP Design ===

'''Inheritance''' is a concept of OOP that facilitates reuse and compartmentalization of code by creating objects (which are collections of attributes and behaviors) that can be derived from existing objects. The deriving object (class) is termed as the ''child class/sub-class/derived class'', and, the object (class) whose methods are being used is called the ''parent class/super-class/base class''. This relationship between the super and sub-classes arising due to inheritance creates a hierarchy amongst the classes. Inheritance is termed as '' Single Inheritance'' if there is only one base class. Languages like C++,Java,Ruby,Python and SmallTalk support inheritance. 

Single inheritance creates a [http://en.wikipedia.org/wiki/Is-a/ Is-A] relationship amongst the classes. Consider the concept of single inheritance using class extension feature:

<pre>
class Animal{
//...
}

class Reptiles extends Animal{
//...
}

</pre>

In the above example, the Reptiles class is a '''specialization''' of Animals class and derives some/all of its attributes and/or methods from the Animal class.

The next section briefly discusses the alternatives of Inheritance used in various OO languages. 

=Definitions=

===Multiple Inheritance===

If a child class inherits behaviors and attributes from two or more parent classes, it is termed as ''Multiple Inheritance''. Languages supporting this feature include C++, Perl and Python. The main advantage of ''Multiple Inheritance'' is that it enables an user to combine independent (and not so independent) concepts (classes) into a composite concept called the derived class. For instance, given a set of ''interaction'' base classes and a set of base classes defining ''display options'', the user can create a new window by selecting a style of window interaction and appearance from the given base classes. 

Suppose there are '''N''' concepts, each of which can be combined with one of '''M''' other concepts, '''N+M''' classes are required to represent all the combined concepts. The situation with N = M = 1 is Single Inheritance. Examples with N>=2 and M>=2 are common and Multiple Inheritance plays an important role in such situations by avoiding replication. 

The following figure depicts the use of multiple inheritance: 

[[Image:UntitledMI.jpg|frame|upright|center|Figure 1. Multiple Inheritance]] 

A novel has a certain number of chapters, characters and other properties that can be thought as features of class STORY. It also has features of class BOOK like publisher, a price, a weight and an ISBN number. Thus, Class NOVEL should inherit from both. 

Following is the code snippet showing the above mentioned example: 

<pre>
class STORY{
//...
}

class BOOK{
//...
}

class NOVEL : public STORY, public BOOK{
//...
}
</pre>
 

===Interfaces===

Java designers cut the features of multiple inheritance and operator overloading from C++ to keep the language ''simple, object oriented and familiar''. '''Interfaces''' were introduced in Java to simulate multiple inheritance. Interfaces (defined using the keyword '''interface''') are [http://en.wikipedia.org/wiki/Abstract_type/ abstract type] containing only the method signatures and constant declarations. A class which implements an interface does so by implementing all its methods. Thus, interfaces act as templates. 

Here's the example showing how interfaces are used in Java:

<pre>

interface Bird
{
public void fly();
}

public class Eagle implements Bird
{
public void fly()
{
System.out.println(“Eagle flies”);
}

public static void main(String args[])
{
Bird bird = new Eagle();
bird.fly();
}
}

public class Duck implements Bird
{
public void fly()
{
System.out.println(“I cannot fly!!”);
}

public static void main(String args[])
{
Bird bird = new Duck();
bird.fly();
}
}
</pre>
 

In the above example, the interface Bird has a method fly(). The Eagle class and the Duck class implement this method in different ways. Since each class making use of the interface has to implement all the methods of the interface, the methods in the interface can be implemented in different ways by different classes.

===Modules===

A module is defined as a component which regroups similar things. Modules differ from classes as modules are just names to regroup things which we think are similar, whereas, classes consist of variables and methods describing the state and the behavior of an entity [1]. A module "protects" the names it contains. The primary benefits of using modules are:

* The code is more organized.
* The risk of name clashes is eliminated as modules provide '''namespace''' facility.
* Mixins can be implemented using modules.

Unlike classes, objects can neither be created nor sub-classed based on modules. Instead, the functionality of a particular module can be specified to be added to a particular class or object. 

Following is an example code snippet showing the use of Modules in Ruby: [7]

<pre>

module takes_courses (parameter)
def takes
puts "student #{parameter} takes course csc517"
end
end

class students
include takes_courses -----> makes the module methods accessible
def student_name( param )
puts "student_name = #{param}"
end
end

student = students.new
#In class
student.student_name 'john' #student name = John

# In Module
student.takes #student John takes course csc517

</pre>

In the above example,A module called takes_courses is defined. This module contains a method called takes which prints the name of the student who has taken the course csc517. The class called students includes the module takes_courses. A new student object is created. This object calls a method (student_name) defined in the class. The output would be "student_name = John ". The same student object is used to call the method takes in the module. This outputs "student John takes course csc 517".

===Mixin===

Mixins are one of the defining features of Ruby that are closely related to ''Duck typing''. Duck typing is a technique that allows usage of objects to respond to a certain set of method calls interchangeably. Mixins are a group of methods that are not yet attached to any class. They exist in a module, and are useful only when they are included in a class. Mixin thus behaves as an interface with implemented methods. 

Mixins cannot be instantiated, but, provide functionality to be inherited by a subclass. Ruby supports only single inheritance. So, mixins prove to be of great importance in Ruby as they simulate multiple inheritance capability in Ruby which allows classes to inherit functionalities from two or more mixins [2],[3],[4].

An Enumeration is a type of mixin module which can be used by all the classes. It does not depend on the language syntax. It is defined as “ an operation that is performed on elements of a set”.Example of enumeration is:
[34, 56, 76, 96].each {|a| puts a}

Following is an example showing the use of mixins: [8]

<pre>

module drawModule
def draw_shape
puts ”draw”
end
end

class parentClass
def shape
puts “shape is circle”
end
end

class circle < parentClass
include drawModule
end

f = circle.new
f.parentClass
f.draw_shape

</pre>

===Traits===

A ''trait'' can be considered as a collection of methods which serves as a simple model for structured object oriented programs [5]. The main difference between mixins and traits lies in the way both are composed. Mixins are composed using only the inheritance operation, but, traits can include symmetric sum, aliasing and method exclusion. Trait is not an abstract type and implements methods. 

With [http://www.iam.unibe.ch/~scg/Research/Traits/ Traits], classes are organized in a single inheritance hierarchy. Traits are basically used to specify incremental differences in the behavior of sub- and super-classes. Traits are supported in programming languages like Fortress,Perl,SmallTalk and Joose framework for JavaScript. 

Traits can be considered as a combination of interfaces that are abstract and their implementation. Here's a Scala trait representing objects that can be compared and ordered: 

<pre>
trait Ord {
def < (that: Any): Boolean
def <=(that: Any): Boolean = (this < that) || (this == that)
def > (that: Any): Boolean = !(this <= that)
def >=(that: Any): Boolean = !(this < that)
}

class Date extends Ord {
def < (that: Any): Boolean = /* implementation */
}

// can now write myDate >= yourDate
</pre> 

As we can see in the above example, Date only needs to implement <. It gets the other operators for free. [9]

= Diamond Problem : Loophole in Multiple Inheritance =

With single inheritance, classes cannot be classified into the branches of the hierarchy and hence, is limiting. Multiple inheritance overcomes this and supports complex relationship models.

But multiple inheritance has the following problems: 

* It is possible that a class inherits multiple features with the same name.
* There can be more than one path to a given ancestor from a class (known as the ''diamond problem '' or ''fork-join'' inheritance) 
* Encapsulation of inheritance: Does a client or inheritor of a class depend on the inheritance structure of that class?
* Common ancestor duplication problem: Should common ancestor be duplicated or not?
* Duplicate parent operation invocation problem: How is this problem of Multiple inheriting from two classes that both invoke the same parent operation on a common ancestor can cause duplicate invocation of this parent operation dealt with?

The conflicting-features problem can be resolved by permitting renaming or by having a linear class hierarchy. The ''diamond problem'' is an ambiguity arising when two classes B and C inherit from class A, and both B and C are inherited by class D. If both classes B and C override the definition of a method inherited from A, then, when class D inherits this same method, conflict arises if D should use the method from B or C.

[[Image:Untitled123.jpg|frame|center|Figure 2. The diamond problem hierarchy]]

In '''C++''', Virtual inheritance was proposed as one solution for class D to inherit only one copy of A's methods. But object initialization is a problem when we have only one copy. Another consequence of diamond problem is that multiple inheritance interacts poorly with modular type-checking of [http://en.wikipedia.org/wiki/Multiple_dispatch/ multiple dispatch].

'''Java''' makes use of the concept of interfaces to simulate Multiple Inheritance and the responsibility of implementing the functions defined in the interfaces lies with the classes making use of the interface. Similarly '''Ruby''' uses the concept of mixins and '''SmallTalk''' and '''Perl''' use Traits. But each solution has its own pros and cons. 

=How mixins solve the Diamond Problem=

Ruby supports only single inheritance, i.e; a given class can inherit from only one parent class. But it is allowed to mixin many modules into a class. Moreover, modules are not permitted to inherit from other modules or classes. As these two conditions have to be always followed, there will be no "diamond" inheritance situation as every class is guaranteed to have a single parent class in case of inheritance. 

As mentioned above, modules can mixin modules. So the following situation (hierarchy) may arise:

<pre>
module P

module Q module R

class X

</pre>

This hierarchy resembles Diamond Problem. But Ruby's method look-up flow [10: http://phrogz.net/RubyLibs/RubyMethodLookupFlow] guarantees that mixin modules are searched before the parent class. Thus, the order of mixing in is significant in Ruby which guarantees that the module/class to be searched is unambiguous. Hence, the diamond problem is avoided.

Though mixins avoid diamond problem, they have a few disadvantages too. The following section does a comparison between the concepts, namely, Multiple Inheritance, Interfaces and Mixins, mentioned above. 

=Comparison =

== Mixins and Interfaces ==

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:25%"|FEATURE
!style="width:25%"|MIXINS
!style="width:25%"|JAVA INTERFACES
|-
|Maintainability
|In Ruby, modules have the implementation of the methods. So all the classes who “include” the module get the same method and its functionality. The definition of the method can change at run time.
|Java forces the classes using the interfaces to implement the methods defined in the interface. This might lead to code duplication if two classes have similar functionality. Secondly, changes have to be made at both places if the method changes in future.
|-
|Size of the Code
|The class/objects automatically get access to the methods of the included module(s).
|If a class inherits multiple interfaces, it is forced to implement unnecessary, and sometimes, duplicate code which makes the code grow in size.
|-
|Readability
|The module and the class using the module can be in different files. Hence, the code is less readable. So mixins are beneficial for individual or small teams. For bigger teams, documentation becomes an important criterion.
|The code is more readable and explicit as the implementation of a method can be found at a place.
|-
|Naming Conflicts
|Modules provide the facility of namespace. So it is possible for a class to inherit two or more methods of same name from different modules.
|Since the class itself has to provide the implementation of the methods, inheriting methods of same names from different interfaces will signal an error message.
|-

|}

== Mixins and C++ Multiple Inheritance ==

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:15%"|
!style="width:25%"|ADVANTAGES
!style="width:25%"|DISADVANTAGES
|-
|MIXINS
|1. Avoids complex features like virtual base classes. 2. Code is less verbose. 3. Modules can be made aware of who included them.
|1. In case of naming conflicts while mixing multiple modules, notification of the error may be incorrect. 2. Ruby is used for implementation inheritance and finds very less use in inheritance implementation. 3. Since it supports non-virtual classes, getting two copies of the base class requires odd code.
|-
|C++ MULTIPLE INHERITANCE
|1. Naming conflicts point to the proper error normally. 2. Can be used for both interface and implementation inheritance. 3. Supports virtual base classes.
|1. C++ classes do not have any knowledge of who inherited them. 2. Poses diamond problem
|-

|}
 
 
In the classic scenario of diamond problem [ Figure 1 ], Ruby simplifies the inheritance to look like D<C<B<A. In C++ Multiple Inheritance, C::foo cannot call B::foo, but with Ruby mix-ins,this is possible. 

= Conclusion =

As we saw, each of the above approaches- Multiple Inheritance, Interfaces, Mixins and Traits - have their own pros and cons. Each one tries to solve the deadly ''Diamond problem'' in a different way, but, no one solves it completely. Traits have the disadvantage that they do not allow states. Different languages try to deal with this problem in a different way. JavaFX technology has introduced mixins too. 

As mentioned in the Sun Microsystem website [[http://java.sun.com/developer/technicalArticles/javafx/mixin/]], ''developers have a new style of class inheritance: a mixin. A mixin is a type of class that can be inherited by a subclass, but it is not meant for instantiation. In this manner, mixins are similar to interfaces in the Java programming language. However, the difference is that mixins may actually define method bodies and class variables in addition to constants and method signatures.'' 

Thus, we can conclude that it is the responsibility of the programmer to make the choice of which mechanism fits the best depending upon the task under consideration.

= References =

[1] http://ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html

[2] http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[3] http://ruby.about.com/od/beginningruby/a/mixin.htm

[4] http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful

[5] http://en.wikipedia.org/wiki/Trait_%28computer_science%29

[6] http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide

[7] http://codeshooter.wordpress.com/2008/09/27/including-and-extending-modules-in-ruby/

[8] http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/

[9] http://hestia.typepad.com/flatlander/2009/01/scala-for-c-programmers-part-1-mixins-and-traits.html

= See Also =

[1] http://www.oreillynet.com/ruby/blog/2007/01/digging_deep_mixing_it_up_or_i_1.html Article from O'Reilly's website which discusses mixins at depth

[2] http://www.sapphiresteel.com/The-Little-Book-Of-Ruby

[3] http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8

[4] http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[5] http://scg.unibe.ch/archive/projects/Reic05a.pdf

[6] http://scg.unibe.ch/archive/phd/schaerli-phd.pdf

CSC/ECE 517 Fall 2010/ch3 3b sv

2010-10-06T20:49:35Z

Vsubram3:

= Multiple Inheritance and Mixins =

'''Inheritance''' is a concept of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] (OOP) that facilitates reuse and compartmentalization of code by creating objects ( which are collections of attributes and behaviors ) which can be derived from existing objects. The deriving object(class) is termed as the ''child class/sub-class/derived class'' , and, the object(class) whose methods are being used is called the ''parent class/super-class/base class''. This relationship between the super and sub-classes arising due to inheritance creates a hierarchy amongst the classes. Inheritance is termed as '' Single Inheritance'' if there is only one base class. Languages like C++,Java,Ruby,Python and SmallTalk support inheritance.

==Definitions==

===Multiple Inheritance===

If a child class inherits behaviors and attributes from two or more parent classes, it is termed as ''Multiple Inheritance''. Languages supporting this feature include C++,Perl and Python. The main advantage of ''Multiple Inheritance'' is that it enables an user to combine independent(and not so independent) concepts(classes) into a composite concept called the derived class. For instance,given a set of ''interaction'' base classes and a set of base classes defining ''display options'', the user can create a new window by selecting a style of window interaction and appearance from the given base classes.

Suppose there are '''N''' concepts, each of which can be combined with one of '''M''' other concepts, '''N+M''' classes are required to represent all the combined concepts. The situation with N = M = 1 is Single Inheritance. Examples with N>=2 and M>=2 are common and Multiple Inheritance plays an important role in such situations by avoiding replication.

===Interfaces===

Java designers cut the features of multiple inheritance and operator overloading from C++ to keep the language ''simple,object oriented and familiar''. '''Interfaces''' were introduced in Java to simulate multiple inheritance. Interfaces (defined using the keyword '''interface''') are [http://en.wikipedia.org/wiki/Abstract_type/ abstract type] containing only the method signatures and constant declarations. A class which implements an interface does so by implementing all its methods. Thus, interfaces act as templates.

===Modules===

A module is defined as a component which regroups similar things. Modules differ from classes as modules are just names to regroup things which we think are similar, whereas, classes consist of variables and methods describing the state and the behavior of an entity [1]. A module "protects" the names it contains. The primary benefits of using modules are:

* The code is more organized.
* The risk of name clashes is eliminated as modules provide '''namespace''' facility.
* Mixins can be implemented using modules.

Unlike classes, objects can neither be created nor sub-classed based on modules. Instead, the functionality of a particular module can be specifies to be added to a particular class or object.

===Mixin===

Mixins are one of the defining features of Ruby that is closely related to ''Duck typing''. Duck typing is a technique that allows usage of objects to respond to a certain set of method calls interchangeably. Mixins are a group of methods that are not yet attached to any class. They exist in a module, and are useful only when they are included in a class. Mixin thus behaves as an interface with implemented methods.

Mixins cannot be instantiated, but, provide functionality to be inherited by a subclass. Ruby supports only single inheritance. So, mixins prove to be of great importance in Ruby as they simulate multiple inheritance capability in Ruby which allows classes to inherit functionalities from two or more mixins [2],[3],[4].

An Enumeration is a type of mixin module which can be used by all the classes.
Its does not depend on the language syntax.
It is defined as “ an operation that is performed on elements of a set”.
example of enumeration is:
[34, 56, 76, 96].each {|a| puts a}

===Traits===

A ''trait'' can be considered as a collection of methods which serves as a simple model for structured object oriented programs [5]. The main difference between mixins and traits lies in the way both are composed. Mixins are composed using only the inheritance operation, but, traits can include symmetric sum, aliasing and method exclusion. Traits is not an abstract type and implements methods.

With [http://www.iam.unibe.ch/~scg/Research/Traits/ Traits], classes are organized in a single inheritance hierarchy. Traits are basically used to specify incremental differences in the behavior of sub- and super-classes. Traits are supported in programming languages like Fortress,Perl,SmallTalk and Joose framework for JavaScript.

= Diamond Problem : Loophole in Multiple Inheritance =

With single inheritance, classes cannot be classified into the branches of the hierarchy and hence, is limiting. Multiple inheritance overcomes this and supports complex relationship models.

But multiple inheritance has the following problems: 

* It is possible that a class inherits multiple features with the same name.
* There can be more than one path to a given ancestor from a class ( known as the ''diamond problem '' or ''fork-join'' inheritance ) 
* Encapsulation of inheritance: Is it allowed for a client or inheritor of a class to depend on the inheritance structure of that class?
* Common ancestor duplication problem: Must the common ancestor be duplicated or not?
* Duplicate parent operation invocation problem: Multiple inheriting from two classes that both invoke the same parent operation on a common ancestor can cause duplicate invocation of this parent operation. How is this problem dealt with?

The conflicting-features problem can be resolved by permitting renaming or by having a linear class hierarchy. The ''diamond problem'' is an ambiguity arising when two classes B and C inherit from class A, and both B and C are inherited by class D. If both classes B and C override the definition of a method inherited from A, then, when class D inherits this same method, conflict arises if D should use the method from B or C.

[[Image:DiamondProblem.jpg|frame|center|Figure 1. The diamond problem hierarchy]]

In '''C++''', Virtual inheritance was proposed as one solution for class D to inherit only one copy of A's methods. But object initialization is a problem when we have only one copy. Another consequence of diamond problem is that multiple inheritance interacts poorly with modular typechecking of [http://en.wikipedia.org/wiki/Multiple_dispatch/ multiple dispatch].

'''Java''' makes use of the concept of interfaces to simulate Multiple Inheritance and the responsibility of implementing the functions defined in the interfaces lies with the classes making use of the interface. Similarly '''Ruby''' uses the concept of mixins and '''SmallTalk''' and '''Perl''' use Traits. But each solution has its own pros and cons.

== Comparison ==

=== Mixins and Interfaces ===

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:25%"|FEATURE
!style="width:25%"|MIXINS
!style="width:25%"|JAVA INTERFACES
|-
|Maintainability
|In Ruby, modules have the implementation of the methods. So all the classes who “include” the module get the same method and its functionality. The definition of the method can change at run time.
|Java forces the classes using the interfaces to implement the methods defined in the interface. This might lead to code duplication if two classes have similar functionality. Secondly, changes have to be made at both places if the method changes in future.
|-
|Size of the Code
|The class/objects automatically get access to the methods of the included module(s).
|If a class inherits multiple interfaces, it is forced to implement unnecessary, and sometimes, duplicate code which makes the code grow in size.
|-
|Readability
|The module and the class using the module can be in different files. Hence, the code is less readable. So mixins are beneficial for individual or small teams. For bigger teams, documentation becomes an important criterion.
|The code is more readable and explicit as the implementation of a method can be found at a place.
|-
|Naming Conflicts
|Modules provide the facility of namespace. So it is possible for a class to inherit two or more methods of same name from different modules.
|Since the class itself has to provide the implementation of the methods, inheriting methods of same names from different interfaces will signal an error message.
|-

|}

=== Mixins and C++ Multiple Inheritance ===

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:15%"|
!style="width:25%"|ADVANTAGES
!style="width:25%"|DISADVANTAGES
|-
|MIXINS
|1. Avoids complex features like virtual base classes. 2. Code is less verbose. 3. Modules can be made aware of who included them.
|1. In case of naming conflicts while mixing multiple modules, notification of the error may be incorrect. 2. Ruby is used for implementation inheritance and finds very less use in inheritance implementation. 3. Since it supports non-virtual classes, getting two copies of the base class requires odd code.
|-
|C++ MULTIPLE INHERITANCE
|1. Naming conflicts point to the proper error normally. 2. Can be used for both interface and implementation inheritance. 3. Supports virtual base classes.
|1. C++ classes do not have any knowledge of who inherited them. 2. Poses diamond problem
|-

|}
 
 
In the classic scenario of diamond problem [ Figure 1 ], Ruby simplifies the inheritance to look like D<C<B<A. In C++ Multiple Inheritance, C::foo cannot call B::foo, but with Ruby mix-ins,this is possible.

= Conclusion =

Each of the above approaches- Multiple Inheritance, Interfaces, Mixins and Traits - have their own pros and cons. Each one tries to solve the deadly ''Diamond problem'' in a different way, but, no one solves it completely. Traits have the disadvantage that they don not allow states. The programmer has to make the choice of which mechanism fits the best depending upon the task under consideration.

= References =

[1] http://ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html

[2] http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[3] http://ruby.about.com/od/beginningruby/a/mixin.htm

[4] http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful

[5] http://en.wikipedia.org/wiki/Trait_%28computer_science%29

[6] http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide

= See Also =

[1] http://www.oreillynet.com/ruby/blog/2007/01/digging_deep_mixing_it_up_or_i_1.html Article from O'Reilly's website which discusses mixins at depth

[2] http://www.sapphiresteel.com/The-Little-Book-Of-Ruby

[3] http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8

[4] http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

CSC/ECE 517 Fall 2010/ch3 3b sv

2010-10-06T20:48:46Z

Vsubram3:

= Multiple Inheritance and Mixins =

'''Inheritance''' is a concept of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] (OOP) that facilitates reuse and compartmentalization of code by creating objects ( which are collections of attributes and behaviors ) which can be derived from existing objects. The deriving object(class) is termed as the ''child class/sub-class/derived class'' , and, the object(class) whose methods are being used is called the ''parent class/super-class/base class''. This relationship between the super and sub-classes arising due to inheritance creates a hierarchy amongst the classes. Inheritance is termed as '' Single Inheritance'' if there is only one base class. Languages like C++,Java,Ruby,Python and SmallTalk support inheritance.

==Definitions==

===Multiple Inheritance===

If a child class inherits behaviors and attributes from two or more parent classes, it is termed as ''Multiple Inheritance''. Languages supporting this feature include C++,Perl and Python. The main advantage of ''Multiple Inheritance'' is that it enables an user to combine independent(and not so independent) concepts(classes) into a composite concept called the derived class. For instance,given a set of ''interaction'' base classes and a set of base classes defining ''display options'', the user can create a new window by selecting a style of window interaction and appearance from the given base classes.

Suppose there are '''N''' concepts, each of which can be combined with one of '''M''' other concepts, '''N+M''' classes are required to represent all the combined concepts. The situation with N = M = 1 is Single Inheritance. Examples with N>=2 and M>=2 are common and Multiple Inheritance plays an important role in such situations by avoiding replication.

===Interfaces===

Java designers cut the features of multiple inheritance and operator overloading from C++ to keep the language ''simple,object oriented and familiar''. '''Interfaces''' were introduced in Java to simulate multiple inheritance. Interfaces (defined using the keyword '''interface''') are [http://en.wikipedia.org/wiki/Abstract_type/ abstract type] containing only the method signatures and constant declarations. A class which implements an interface does so by implementing all its methods. Thus, interfaces act as templates.

===Modules===

A module is defined as a component which regroups similar things. Modules differ from classes as modules are just names to regroup things which we think are similar, whereas, classes consist of variables and methods describing the state and the behavior of an entity [1]. A module "protects" the names it contains. The primary benefits of using modules are:

* The code is more organized.
* The risk of name clashes is eliminated as modules provide '''namespace''' facility.
* Mixins can be implemented using modules.

Unlike classes, objects can neither be created nor sub-classed based on modules. Instead, the functionality of a particular module can be specifies to be added to a particular class or object.

Example:

module drawModule
Def draw_shape
Puts ”draw”
End
End

Class Parentclass
Def shape
Puts “shape is circle”
End
End

Class circle < parentclass
Include drawModule
end

f = circle.new
f.parentclass
f.draw_shape

===Mixin===

Mixins are one of the defining features of Ruby that is closely related to ''Duck typing''. Duck typing is a technique that allows usage of objects to respond to a certain set of method calls interchangeably. Mixins are a group of methods that are not yet attached to any class. They exist in a module, and are useful only when they are included in a class. Mixin thus behaves as an interface with implemented methods.

Mixins cannot be instantiated, but, provide functionality to be inherited by a subclass. Ruby supports only single inheritance. So, mixins prove to be of great importance in Ruby as they simulate multiple inheritance capability in Ruby which allows classes to inherit functionalities from two or more mixins [2],[3],[4].

An Enumeration is a type of mixin module which can be used by all the classes.
Its does not depend on the language syntax.
It is defined as “ an operation that is performed on elements of a set”.
example of enumeration is:
[34, 56, 76, 96].each {|a| puts a}

===Traits===

A ''trait'' can be considered as a collection of methods which serves as a simple model for structured object oriented programs [5]. The main difference between mixins and traits lies in the way both are composed. Mixins are composed using only the inheritance operation, but, traits can include symmetric sum, aliasing and method exclusion. Traits is not an abstract type and implements methods.

With [http://www.iam.unibe.ch/~scg/Research/Traits/ Traits], classes are organized in a single inheritance hierarchy. Traits are basically used to specify incremental differences in the behavior of sub- and super-classes. Traits are supported in programming languages like Fortress,Perl,SmallTalk and Joose framework for JavaScript.

= Diamond Problem : Loophole in Multiple Inheritance =

With single inheritance, classes cannot be classified into the branches of the hierarchy and hence, is limiting. Multiple inheritance overcomes this and supports complex relationship models.

But multiple inheritance has the following problems: 

* It is possible that a class inherits multiple features with the same name.
* There can be more than one path to a given ancestor from a class ( known as the ''diamond problem '' or ''fork-join'' inheritance ) 
* Encapsulation of inheritance: Is it allowed for a client or inheritor of a class to depend on the inheritance structure of that class?
* Common ancestor duplication problem: Must the common ancestor be duplicated or not?
* Duplicate parent operation invocation problem: Multiple inheriting from two classes that both invoke the same parent operation on a common ancestor can cause duplicate invocation of this parent operation. How is this problem dealt with?

The conflicting-features problem can be resolved by permitting renaming or by having a linear class hierarchy. The ''diamond problem'' is an ambiguity arising when two classes B and C inherit from class A, and both B and C are inherited by class D. If both classes B and C override the definition of a method inherited from A, then, when class D inherits this same method, conflict arises if D should use the method from B or C.

[[Image:DiamondProblem.jpg|frame|center|Figure 1. The diamond problem hierarchy]]

In '''C++''', Virtual inheritance was proposed as one solution for class D to inherit only one copy of A's methods. But object initialization is a problem when we have only one copy. Another consequence of diamond problem is that multiple inheritance interacts poorly with modular typechecking of [http://en.wikipedia.org/wiki/Multiple_dispatch/ multiple dispatch].

'''Java''' makes use of the concept of interfaces to simulate Multiple Inheritance and the responsibility of implementing the functions defined in the interfaces lies with the classes making use of the interface. Similarly '''Ruby''' uses the concept of mixins and '''SmallTalk''' and '''Perl''' use Traits. But each solution has its own pros and cons.

== Comparison ==

=== Mixins and Interfaces ===

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:25%"|FEATURE
!style="width:25%"|MIXINS
!style="width:25%"|JAVA INTERFACES
|-
|Maintainability
|In Ruby, modules have the implementation of the methods. So all the classes who “include” the module get the same method and its functionality. The definition of the method can change at run time.
|Java forces the classes using the interfaces to implement the methods defined in the interface. This might lead to code duplication if two classes have similar functionality. Secondly, changes have to be made at both places if the method changes in future.
|-
|Size of the Code
|The class/objects automatically get access to the methods of the included module(s).
|If a class inherits multiple interfaces, it is forced to implement unnecessary, and sometimes, duplicate code which makes the code grow in size.
|-
|Readability
|The module and the class using the module can be in different files. Hence, the code is less readable. So mixins are beneficial for individual or small teams. For bigger teams, documentation becomes an important criterion.
|The code is more readable and explicit as the implementation of a method can be found at a place.
|-
|Naming Conflicts
|Modules provide the facility of namespace. So it is possible for a class to inherit two or more methods of same name from different modules.
|Since the class itself has to provide the implementation of the methods, inheriting methods of same names from different interfaces will signal an error message.
|-

|}

=== Mixins and C++ Multiple Inheritance ===

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:15%"|
!style="width:25%"|ADVANTAGES
!style="width:25%"|DISADVANTAGES
|-
|MIXINS
|1. Avoids complex features like virtual base classes. 2. Code is less verbose. 3. Modules can be made aware of who included them.
|1. In case of naming conflicts while mixing multiple modules, notification of the error may be incorrect. 2. Ruby is used for implementation inheritance and finds very less use in inheritance implementation. 3. Since it supports non-virtual classes, getting two copies of the base class requires odd code.
|-
|C++ MULTIPLE INHERITANCE
|1. Naming conflicts point to the proper error normally. 2. Can be used for both interface and implementation inheritance. 3. Supports virtual base classes.
|1. C++ classes do not have any knowledge of who inherited them. 2. Poses diamond problem
|-

|}
 
 
In the classic scenario of diamond problem [ Figure 1 ], Ruby simplifies the inheritance to look like D<C<B<A. In C++ Multiple Inheritance, C::foo cannot call B::foo, but with Ruby mix-ins,this is possible.

= Conclusion =

Each of the above approaches- Multiple Inheritance, Interfaces, Mixins and Traits - have their own pros and cons. Each one tries to solve the deadly ''Diamond problem'' in a different way, but, no one solves it completely. Traits have the disadvantage that they don not allow states. The programmer has to make the choice of which mechanism fits the best depending upon the task under consideration.

= References =

[1] http://ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html

[2] http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[3] http://ruby.about.com/od/beginningruby/a/mixin.htm

[4] http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful

[5] http://en.wikipedia.org/wiki/Trait_%28computer_science%29

[6] http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide

= See Also =

[1] http://www.oreillynet.com/ruby/blog/2007/01/digging_deep_mixing_it_up_or_i_1.html Article from O'Reilly's website which discusses mixins at depth

[2] http://www.sapphiresteel.com/The-Little-Book-Of-Ruby

[3] http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8

[4] http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

CSC/ECE 517 Fall 2010/ch3 3b sv

2010-10-06T20:47:34Z

Vsubram3:

= Multiple Inheritance and Mixins =

'''Inheritance''' is a concept of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] (OOP) that facilitates reuse and compartmentalization of code by creating objects ( which are collections of attributes and behaviors ) which can be derived from existing objects. The deriving object(class) is termed as the ''child class/sub-class/derived class'' , and, the object(class) whose methods are being used is called the ''parent class/super-class/base class''. This relationship between the super and sub-classes arising due to inheritance creates a hierarchy amongst the classes. Inheritance is termed as '' Single Inheritance'' if there is only one base class. Languages like C++,Java,Ruby,Python and SmallTalk support inheritance.

==Definitions==

===Multiple Inheritance===

If a child class inherits behaviors and attributes from two or more parent classes, it is termed as ''Multiple Inheritance''. Languages supporting this feature include C++,Perl and Python. The main advantage of ''Multiple Inheritance'' is that it enables an user to combine independent(and not so independent) concepts(classes) into a composite concept called the derived class. For instance,given a set of ''interaction'' base classes and a set of base classes defining ''display options'', the user can create a new window by selecting a style of window interaction and appearance from the given base classes.

Suppose there are '''N''' concepts, each of which can be combined with one of '''M''' other concepts, '''N+M''' classes are required to represent all the combined concepts. The situation with N = M = 1 is Single Inheritance. Examples with N>=2 and M>=2 are common and Multiple Inheritance plays an important role in such situations by avoiding replication.

===Interfaces===

Java designers cut the features of multiple inheritance and operator overloading from C++ to keep the language ''simple,object oriented and familiar''. '''Interfaces''' were introduced in Java to simulate multiple inheritance. Interfaces (defined using the keyword '''interface''') are [http://en.wikipedia.org/wiki/Abstract_type/ abstract type] containing only the method signatures and constant declarations. A class which implements an interface does so by implementing all its methods. Thus, interfaces act as templates.

===Modules===

A module is defined as a component which regroups similar things. Modules differ from classes as modules are just names to regroup things which we think are similar, whereas, classes consist of variables and methods describing the state and the behavior of an entity [1]. A module "protects" the names it contains. The primary benefits of using modules are:

* The code is more organized.
* The risk of name clashes is eliminated as modules provide '''namespace''' facility.
* Mixins can be implemented using modules.

Unlike classes, objects can neither be created nor sub-classed based on modules. Instead, the functionality of a particular module can be specifies to be added to a particular class or object.

Example:

module drawModule
Def draw_shape
Puts ”draw”
End
End

Class Parentclass
Def shape
Puts “shape is circle”
End
End

Class circle < parentclass
Include drawModule
end

f = circle.new
f.parentclass
f.draw_shape

===Mixin===

Mixins are one of the defining features of Ruby that is closely related to ''Duck typing''. Duck typing is a technique that allows usage of objects to respond to a certain set of method calls interchangeably. Mixins are a group of methods that are not yet attached to any class. They exist in a module, and are useful only when they are included in a class. Mixin thus behaves as an interface with implemented methods.

Mixins cannot be instantiated, but, provide functionality to be inherited by a subclass. Ruby supports only single inheritance. So, mixins prove to be of great importance in Ruby as they simulate multiple inheritance capability in Ruby which allows classes to inherit functionalities from two or more mixins [2],[3],[4].

An Enumeration is a type of mixin module which can be used by all the classes.
Its does not depend on the language syntax.
It is defined as “ an operation that is performed on elements of a set”.
example of enumeration is:
[34, 56, 76, 96].each {|a| puts a}

===Traits===

A ''trait'' can be considered as a collection of methods which serves as a simple model for structured object oriented programs [5]. The main difference between mixins and traits lies in the way both are composed. Mixins are composed using only the inheritance operation, but, traits can include symmetric sum, aliasing and method exclusion. Traits is not an abstract type and implements methods.

With [http://www.iam.unibe.ch/~scg/Research/Traits/ Traits], classes are organized in a single inheritance hierarchy. Traits are basically used to specify incremental differences in the behavior of sub- and super-classes. Traits are supported in programming languages like Fortress,Perl,SmallTalk and Joose framework for JavaScript.

= Diamond Problem : Loophole in Multiple Inheritance =

With single inheritance, classes cannot be classified into the branches of the hierarchy and hence, is limiting. Multiple inheritance overcomes this and supports complex relationship models.

But multiple inheritance has the following problems: 

* It is possible that a class inherits multiple features with the same name.
* There can be more than one path to a given ancestor from a class ( known as the ''diamond problem '' or ''fork-join'' inheritance ) 
* Encapsulation of inheritance: Is it allowed for a client or inheritor of a class to depend on the inheritance structure of that class?
* Common ancestor duplication problem: Must the common ancestor be duplicated or not?
* Duplicate parent operation invocation problem: Multiple inheriting from two classes that both invoke the same parent operation on a common ancestor can cause duplicate invocation of this parent operation. How is this problem dealt with?

The conflicting-features problem can be resolved by permitting renaming or by having a linear class hierarchy. The ''diamond problem'' is an ambiguity arising when two classes B and C inherit from class A, and both B and C are inherited by class D. If both classes B and C override the definition of a method inherited from A, then, when class D inherits this same method, conflict arises if D should use the method from B or C.

[[Image:DiamondProblem.jpg|frame|center|Figure 1. The diamond problem hierarchy]]

In '''C++''', Virtual inheritance was proposed as one solution for class D to inherit only one copy of A's methods. But object initialization is a problem when we have only one copy. Another consequence of diamond problem is that multiple inheritance interacts poorly with modular typechecking of [http://en.wikipedia.org/wiki/Multiple_dispatch/ multiple dispatch].

'''Java''' makes use of the concept of interfaces to simulate Multiple Inheritance and the responsibility of implementing the functions defined in the interfaces lies with the classes making use of the interface. Similarly '''Ruby''' uses the concept of mixins and '''SmallTalk''' and '''Perl''' use Traits. But each solution has its own pros and cons.

== Comparison ==

=== Mixins and Interfaces ===

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:25%"|FEATURE
!style="width:25%"|MIXINS
!style="width:25%"|JAVA INTERFACES
|-
|Maintainability
|In Ruby, modules have the implementation of the methods. So all the classes who “include” the module get the same method and its functionality. The definition of the method can change at run time.
|Java forces the classes using the interfaces to implement the methods defined in the interface. This might lead to code duplication if two classes have similar functionality. Secondly, changes have to be made at both places if the method changes in future.
|-
|Size of the Code
|The class/objects automatically get access to the methods of the included module(s).
|If a class inherits multiple interfaces, it is forced to implement unnecessary, and sometimes, duplicate code which makes the code grow in size.
|-
|Readability
|The module and the class using the module can be in different files. Hence, the code is less readable. So mixins are beneficial for individual or small teams. For bigger teams, documentation becomes an important criterion.
|The code is more readable and explicit as the implementation of a method can be found at a place.
|-
|Naming Conflicts
|Modules provide the facility of namespace. So it is possible for a class to inherit two or more methods of same name from different modules.
|Since the class itself has to provide the implementation of the methods, inheriting methods of same names from different interfaces will signal an error message.
|-

|}

=== Mixins and C++ Multiple Inheritance ===

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:15%"|
!style="width:25%"|ADVANTAGES
!style="width:25%"|DISADVANTAGES
|-
|MIXINS
|1. Avoids complex features like virtual base classes. 2. Code is less verbose. 3. Modules can be made aware of who included them.
|1. In case of naming conflicts while mixing multiple modules, notification of the error may be incorrect. 2. Ruby is used for implementation inheritance and finds very less use in inheritance implementation. 3. Since it supports non-virtual classes, getting two copies of the base class requires odd code.
|-
|C++ MULTIPLE INHERITANCE
|1. Naming conflicts point to the proper error normally. 2. Can be used for both interface and implementation inheritance. 3. Supports virtual base classes.
|1. C++ classes do not have any knowledge of who inherited them. 2. Poses diamond problem
|-

|}
 
 
In the classic scenario of diamond problem [ Figure 1 ], Ruby simplifies the inheritance to look like D<C<B<A. In C++ Multiple Inheritance, C::foo cannot call B::foo, but with Ruby mix-ins,this is possible.

= Conclusion =

Each of the above approaches- Multiple Inheritance, Interfaces, Mixins and Traits - have their own pros and cons. Each one tries to solve the deadly ''Diamond problem'' in a different way, but, no one solves it completely. Traits have the disadvantage that they don not allow states. The programmer has to make the choice of which mechanism fits the best depending upon the task under consideration.

= References =

[1] http://ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html

[2] http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[3] http://ruby.about.com/od/beginningruby/a/mixin.htm

[4] http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful

[5] http://en.wikipedia.org/wiki/Trait_%28computer_science%29

[6] http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide

= See Also =

[1] http://www.oreillynet.com/ruby/blog/2007/01/digging_deep_mixing_it_up_or_i_1.html Article from O'Reilly's website which discusses mixins at depth

[2] http://www.sapphiresteel.com/The-Little-Book-Of-Ruby

[3] http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8

[4] http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

CSC/ECE 517 Fall 2010/ch3 3b sv

2010-10-06T20:46:00Z

Vsubram3:

= Multiple Inheritance and Mixins =

'''Inheritance''' is a concept of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] (OOP) that facilitates reuse and compartmentalization of code by creating objects ( which are collections of attributes and behaviors ) which can be derived from existing objects. The deriving object(class) is termed as the ''child class/sub-class/derived class'' , and, the object(class) whose methods are being used is called the ''parent class/super-class/base class''. This relationship between the super and sub-classes arising due to inheritance creates a hierarchy amongst the classes. Inheritance is termed as '' Single Inheritance'' if there is only one base class. Languages like C++,Java,Ruby,Python and SmallTalk support inheritance.

==Definitions==

===Multiple Inheritance===

If a child class inherits behaviors and attributes from two or more parent classes, it is termed as ''Multiple Inheritance''. Languages supporting this feature include C++,Perl and Python. The main advantage of ''Multiple Inheritance'' is that it enables an user to combine independent(and not so independent) concepts(classes) into a composite concept called the derived class. For instance,given a set of ''interaction'' base classes and a set of base classes defining ''display options'', the user can create a new window by selecting a style of window interaction and appearance from the given base classes.

Suppose there are '''N''' concepts, each of which can be combined with one of '''M''' other concepts, '''N+M''' classes are required to represent all the combined concepts. The situation with N = M = 1 is Single Inheritance. Examples with N>=2 and M>=2 are common and Multiple Inheritance plays an important role in such situations by avoiding replication.

===Interfaces===

Java designers cut the features of multiple inheritance and operator overloading from C++ to keep the language ''simple,object oriented and familiar''. '''Interfaces''' were introduced in Java to simulate multiple inheritance. Interfaces (defined using the keyword '''interface''') are [http://en.wikipedia.org/wiki/Abstract_type/ abstract type] containing only the method signatures and constant declarations. A class which implements an interface does so by implementing all its methods. Thus, interfaces act as templates.

===Modules===

A module is defined as a component which regroups similar things. Modules differ from classes as modules are just names to regroup things which we think are similar, whereas, classes consist of variables and methods describing the state and the behavior of an entity [1]. A module "protects" the names it contains. The primary benefits of using modules are:

* The code is more organized.
* The risk of name clashes is eliminated as modules provide '''namespace''' facility.
* Mixins can be implemented using modules.

Unlike classes, objects can neither be created nor sub-classed based on modules. Instead, the functionality of a particular module can be specifies to be added to a particular class or object.

Example:
module drawModule
Def draw_shape
Puts ”draw”
End
End

Class Parentclass
Def shape
Puts “shape is circle”
End
End

Class circle < parentclass
Include drawModule
end

f = circle.new
f.parentclass
f.draw_shape

===Mixin===

Mixins are one of the defining features of Ruby that is closely related to ''Duck typing''. Duck typing is a technique that allows usage of objects to respond to a certain set of method calls interchangeably. Mixins are a group of methods that are not yet attached to any class. They exist in a module, and are useful only when they are included in a class. Mixin thus behaves as an interface with implemented methods.

Mixins cannot be instantiated, but, provide functionality to be inherited by a subclass. Ruby supports only single inheritance. So, mixins prove to be of great importance in Ruby as they simulate multiple inheritance capability in Ruby which allows classes to inherit functionalities from two or more mixins [2],[3],[4].

An Enumeration is a type of mixin module which can be used by all the classes.
Its does not depend on the language syntax.
It is defined as “ an operation that is performed on elements of a set”.
example of enumeration is:
[34, 56, 76, 96].each {|a| puts a}

===Traits===

A ''trait'' can be considered as a collection of methods which serves as a simple model for structured object oriented programs [5]. The main difference between mixins and traits lies in the way both are composed. Mixins are composed using only the inheritance operation, but, traits can include symmetric sum, aliasing and method exclusion. Traits is not an abstract type and implements methods.

With [http://www.iam.unibe.ch/~scg/Research/Traits/ Traits], classes are organized in a single inheritance hierarchy. Traits are basically used to specify incremental differences in the behavior of sub- and super-classes. Traits are supported in programming languages like Fortress,Perl,SmallTalk and Joose framework for JavaScript.

= Diamond Problem : Loophole in Multiple Inheritance =

With single inheritance, classes cannot be classified into the branches of the hierarchy and hence, is limiting. Multiple inheritance overcomes this and supports complex relationship models.

But multiple inheritance has the following problems: 

* It is possible that a class inherits multiple features with the same name.
* There can be more than one path to a given ancestor from a class ( known as the ''diamond problem '' or ''fork-join'' inheritance ) 
* Encapsulation of inheritance: Is it allowed for a client or inheritor of a class to depend on the inheritance structure of that class?
* Common ancestor duplication problem: Must the common ancestor be duplicated or not?
* Duplicate parent operation invocation problem: Multiple inheriting from two classes that both invoke the same parent operation on a common ancestor can cause duplicate invocation of this parent operation. How is this problem dealt with?

The conflicting-features problem can be resolved by permitting renaming or by having a linear class hierarchy. The ''diamond problem'' is an ambiguity arising when two classes B and C inherit from class A, and both B and C are inherited by class D. If both classes B and C override the definition of a method inherited from A, then, when class D inherits this same method, conflict arises if D should use the method from B or C.

[[Image:DiamondProblem.jpg|frame|center|Figure 1. The diamond problem hierarchy]]

In '''C++''', Virtual inheritance was proposed as one solution for class D to inherit only one copy of A's methods. But object initialization is a problem when we have only one copy. Another consequence of diamond problem is that multiple inheritance interacts poorly with modular typechecking of [http://en.wikipedia.org/wiki/Multiple_dispatch/ multiple dispatch].

'''Java''' makes use of the concept of interfaces to simulate Multiple Inheritance and the responsibility of implementing the functions defined in the interfaces lies with the classes making use of the interface. Similarly '''Ruby''' uses the concept of mixins and '''SmallTalk''' and '''Perl''' use Traits. But each solution has its own pros and cons.

== Comparison ==

=== Mixins and Interfaces ===

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:25%"|FEATURE
!style="width:25%"|MIXINS
!style="width:25%"|JAVA INTERFACES
|-
|Maintainability
|In Ruby, modules have the implementation of the methods. So all the classes who “include” the module get the same method and its functionality. The definition of the method can change at run time.
|Java forces the classes using the interfaces to implement the methods defined in the interface. This might lead to code duplication if two classes have similar functionality. Secondly, changes have to be made at both places if the method changes in future.
|-
|Size of the Code
|The class/objects automatically get access to the methods of the included module(s).
|If a class inherits multiple interfaces, it is forced to implement unnecessary, and sometimes, duplicate code which makes the code grow in size.
|-
|Readability
|The module and the class using the module can be in different files. Hence, the code is less readable. So mixins are beneficial for individual or small teams. For bigger teams, documentation becomes an important criterion.
|The code is more readable and explicit as the implementation of a method can be found at a place.
|-
|Naming Conflicts
|Modules provide the facility of namespace. So it is possible for a class to inherit two or more methods of same name from different modules.
|Since the class itself has to provide the implementation of the methods, inheriting methods of same names from different interfaces will signal an error message.
|-

|}

=== Mixins and C++ Multiple Inheritance ===

{|cellspacing="0" border="2" style="color:black; background-color:LightYellow;"
!style="width:15%"|
!style="width:25%"|ADVANTAGES
!style="width:25%"|DISADVANTAGES
|-
|MIXINS
|1. Avoids complex features like virtual base classes. 2. Code is less verbose. 3. Modules can be made aware of who included them.
|1. In case of naming conflicts while mixing multiple modules, notification of the error may be incorrect. 2. Ruby is used for implementation inheritance and finds very less use in inheritance implementation. 3. Since it supports non-virtual classes, getting two copies of the base class requires odd code.
|-
|C++ MULTIPLE INHERITANCE
|1. Naming conflicts point to the proper error normally. 2. Can be used for both interface and implementation inheritance. 3. Supports virtual base classes.
|1. C++ classes do not have any knowledge of who inherited them. 2. Poses diamond problem
|-

|}
 
 
In the classic scenario of diamond problem [ Figure 1 ], Ruby simplifies the inheritance to look like D<C<B<A. In C++ Multiple Inheritance, C::foo cannot call B::foo, but with Ruby mix-ins,this is possible.

= Conclusion =

Each of the above approaches- Multiple Inheritance, Interfaces, Mixins and Traits - have their own pros and cons. Each one tries to solve the deadly ''Diamond problem'' in a different way, but, no one solves it completely. Traits have the disadvantage that they don not allow states. The programmer has to make the choice of which mechanism fits the best depending upon the task under consideration.

= References =

[1] http://ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html

[2] http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

[3] http://ruby.about.com/od/beginningruby/a/mixin.htm

[4] http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful

[5] http://en.wikipedia.org/wiki/Trait_%28computer_science%29

[6] http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide

= See Also =

[1] http://www.oreillynet.com/ruby/blog/2007/01/digging_deep_mixing_it_up_or_i_1.html Article from O'Reilly's website which discusses mixins at depth

[2] http://www.sapphiresteel.com/The-Little-Book-Of-Ruby

[3] http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8

[4] http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/

CSC/ECE 517 Fall 2010/ch3 3b sv

2010-10-06T20:25:14Z

Vsubram3: