CSC/ECE 517 Fall 2009/wiki2 11 sv: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
== '''Design patterns''' ==
== '''Design patterns''' ==
The idea of design pattern was first introduced by the architect [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander] in the field of architecture. Later it has been adapted for various other disciplines, including computer science.
The idea of design pattern was first introduced by the architect [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander] in the field of architecture. Later it has been adapted for various other disciplines, including computer science. Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context [1].


A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. In software engineering, a design pattern is a solution to a general and commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. But it is a description or template for how to solve a problem that can be used in many different situations.
In general, a pattern has four essential elements:
 
#The '''pattern name''' is a handle used to describe a design problem, its solutions, and consequences in a word or two.  
#The '''problem''' explains the problem and its context and also describes when to apply the pattern.
#The '''solution''' describes the elements that make up the design, their relationships, responsibilities, and collaborations.the pattern provides an abstract description of a design problem and how a general arrangement of elements solves it.
#The '''consequences''' are the results and trade-offs of applying the pattern.  


e.g.


<pre>We can find some common steps or building blocks in any process. Suppose we have to build a home. Then high level of disign
A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. In software engineering, a design pattern is a solution to a general and commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. But it is a description or template for how to solve a problem that can be used in many different situations.
will be based on how many rooms do we wish to have on each floor. once we are done with this then its just the matter of
duplicating it for the other floors. This is very common and basic design for construction.
</pre>


----
----

Revision as of 02:25, 9 October 2009

Design patterns

The idea of design pattern was first introduced by the architect Christopher Alexander in the field of architecture. Later it has been adapted for various other disciplines, including computer science. Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context [1].

In general, a pattern has four essential elements:

  1. The pattern name is a handle used to describe a design problem, its solutions, and consequences in a word or two.
  2. The problem explains the problem and its context and also describes when to apply the pattern.
  3. The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations.the pattern provides an abstract description of a design problem and how a general arrangement of elements solves it.
  4. The consequences are the results and trade-offs of applying the pattern.


A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. In software engineering, a design pattern is a solution to a general and commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. But it is a description or template for how to solve a problem that can be used in many different situations.


Design patterns in ruby

Almost every design patterns of ruby are borrowed from the GOF book. Following is the list of common pattern used in ruby.

  1. Template
  2. Strategy
  3. Observer
  4. Composite
  5. Iterator
  6. Commands
  7. Adapter
  8. Proxy
  9. Decorator
  10. Singleton
  11. Factory
  12. Builder
  13. Interpreter

Factory



Observer


Introduction:

The observer pattern (sometimes known as publish/subscribe) is a software design pattern in which an object, called the 'subject', maintains a list of its dependents, called 'observers', and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.

Example Scenario where Observer Pattern is Used:
Consider a personnel system where an employee's salary changes and the payroll department needs to know when these changes take place. Here, How can one make the Employee object spread the news about salary changes without tangling it up with the payroll system? In such a situation, Observer pattern is used. Initially, an object is created that is interested in the state of a person's(any employee's) finances. This object then needs to simply register with that person's 'Employee Object' ahead of time. Once registered, that object would receive timely updates about the ups and downs of the person's paycheck.

Here is a basic version of an Employee object that tracks an employee. It does not have any code that tells about any salary updates.

class Employee
attr_reader :name
attr_accessor :title, :salary
def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
end
end


The employees can get raises because we made the salary field accessible with attr_accessor.

jim = Employee.new("Jim Flintstone", "Crane Operator", 5000.0)
# Give Jim a raise
jim.salary=8000.0


Now, adding some code to keep the payroll department informed of pay changes:

class Payroll
def update( changed_employee )
puts("Cut a new check for #{changed_employee.name}!")
puts("His salary is now #{changed_employee.salary}!")
end
end


class Employee
attr_reader :name, :title
attr_reader :salary
def initialize( name, title, salary,payroll)
@name = name
@title = title
@salary = salary
@payroll = payroll
end
def salary=(new_salary)
@salary = new_salary
@payroll.update(self)
end
end


Strategy



Conclusion


See Also

[1]

[2]


[3]

[4]

[5]

[6]



References

[1]

[2]

[3]