CSC/ECE 517 Fall 2010/ch7 7a AV: Difference between revisions
(28 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
=Novel implementations of design patterns in dynamic 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. | 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== | ==Importance of design patterns in programming languages== | ||
i. In a given context, design patterns can be a reusable solution for a general problem.<br> | i. In a given context, design patterns can be a reusable solution for a general problem. [http://sourcemaking.com/design_patterns 1] <br> | ||
ii. For the benefit of novice programmers, design patterns are usually documented systematically. <br> | ii. For the benefit of novice programmers, design patterns are usually documented systematically. <br> | ||
iii. Design patterns help us to learn from the experience of other software developers. <br> | iii. Design patterns help us to learn from the experience of other software developers. <br> | ||
Line 15: | Line 15: | ||
==How to choose a particular design pattern?== | ==How to choose a particular design pattern?== | ||
i. Identify the different classes and methods for a given problem.<br> | i. Identify the different classes and methods for a given problem. [http://c2.com/cgi/wiki?DesignPatterns 3] <br> | ||
ii. Recognize the different solutions that can be used to solve the problem.<br> | ii. Recognize the different solutions that can be used to solve the problem.<br> | ||
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context.<br> | iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context.<br> | ||
iv. Recognize the language limitations for each of the design patterns.<br> | iv. Recognize the language limitations for each of the design patterns.<br> | ||
v. Finally choose the most suitable and efficient design.<br> | v. Finally choose the most suitable and efficient design.<br> | ||
=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> | |||
<br> | |||
Output:<br> | |||
1<br> | |||
4<br> | |||
9<br> | |||
25<br> | |||
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<br> | |||
1 is a odd number<br> | |||
2 is a even number<br> | |||
3 is a odd number<br> | |||
5 is a odd number<br> | |||
=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] |
Latest revision as of 01:26, 13 December 2010
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. 5 2
Importance of design patterns in programming languages
i. In a given context, design patterns can be a reusable solution for a general problem. 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. 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. 11 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. 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. 6
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. 8
Implementation of observer pattern in ruby
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
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
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
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. 7
Fig 6.1 Use Case diagram for Observer pattern
Implementation of Decorator pattern in ruby
module Decorator def initialize(decorated) @decorated = decorated end end
class SimplePizza def price @price = 5 end end
class OnionTopping include Decorator def price @price = @decorated.price+ 1.1 end end
class CheeseTopping include Decorator def price @decorated.price + 1.0 end end
#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}"
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. 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. 10
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.
def square_arrayElements (array) array.each {|a| puts a*a } end
array = [1,2,3,5] square_arrayElements(array)
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.
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
array1 = [1,2,3,5] evenOrodd(array)
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
- [3]: Design Patterns wiki
- [4]: irisa
- [5]: Slides, uottawa
- [11]: uottawa