CSC/ECE 517 Fall 2010/ch7 7a AV

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

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