CSC/ECE 517 Fall 2010/ch7 7a AV: Difference between revisions
| Line 30: | Line 30: | ||
This pattern is used in the context, where frequent updates of different states take 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. | 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== | |||
Revision as of 07:04, 1 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.
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.