http://www.flickr.com/photos/ajari/2287240221/sizes/l/

• You need to hang a poster on the wall…
• What do you do?
• You need to write a term paper…
• How should it be organized?

• Design patterns (DPs) are…
• Strategies for your “toolkit of ideas”
• Templates for solutions
• Codified best practices
• Design patterns are not…
• Architectural styles (DPs are too low level)
• Code libraries (DPs are ideas, not code)

• Design patterns (DPs) can be characterized as “a three part rule which express a relation between a certain context, a problem and a solution.”
• A set of requirements including limitations and
constraints acts as a system of forces that influences how the problem can be interpreted within its context and how the solution can be effectively applied.

• situation/context: : NY to LA (road, airlines,airways)
• System of forces: how quick the person wants to reach, whether the trip will include stopover and site-seeing, how much money willing to spend, is it for a purpose-the travel, and what vehicles are at the persons disposal.
• Based on the context and the system of forces the solution might vary.

• It solves a problem.
• It’s a proven concept.
• The solution isn't obvious.
• It describes a relationship.
• The pattern has a significant human component
(minimize human intervention).

• Primary goals of DPs
• To help maintainability, flexibility, other quality attributes
• To help system designers make good decisions
• There are a few dozen very common OO patterns
• Patterns exist for other kinds of non-OO systems.
• Patterns are recognizable based on their structure and their purpose .

• Traffic example
Design patterns span a broad spectrum of abstraction and application: a) Architectural pattern b) Data patterns: data modeling solutions.
c) Component patterns/design patterns: d) Interface design patterns.
e) Webapp patterns.

• Creational patterns: creation, composition and representation of objects (encapsulation)
• Structural patterns: focuses on problems and solutions associated with how classes and objects are organized and integrated to build a larger structure.
• Behavioral patterns: address problems associated with the assignment of responsibility between objects and the manner in which communication is effected between objects.

• Kiva system to connect lenders with borrowers
• How could we use
DPs to implement
Kiva?
• How could we use
DPs to implement a better Kiva???

Builder
Knows how to create a complex object
Use when instantiating an object requires filling it with parts or otherwise lengthy configuration
TeamReviewScreenBuilder
+generateHtml()
TeamReviewScreen
SearchSection
CategoryFilterSection
TeamTable
TeamHeading
TeamRow
+ image
+ name
+ creation date
+ # members
+ # loans
+ total loaned
+ Join button
TeamInfo
+ link
+ category

Adapter
Converts one interface to another by wrapping
Use to overcome incompatibility
PaymentProcessor
+ pay($ amount)
CreditCardPaymentAdapter
+ pay($ amount)
.netCharge component
+ issueCharge($ amount, timeout)
Remote credit card gateway

Facade
Object that provides a unified, high-level interface to a subsystem
Use when calling a subsystem requires a frequent series of complex lines of code
PaymentProcessor
+ pay($ amount)
CreditCardPaymentAdapter
+ pay($ amount)
.netCharge component
+ issueCharge($ amount, timeout)
ComponentLicense
GatewayProxy
GatewayRequest
Remote server
RequestConfiguration
+ timeout
+ URL
+ HTTP client certificate

Memento
Encapsulate state in an object
BlogEntryEditor
Use if you might want to return to a certain state later BlogEntry
+ StoreToHtmlMemento()
+ ReloadFromHtmlMemento()
UndoRedoManager
HtmlMemento
+ html

Interpreter
Parses and acts on instructions written in a certain syntax
Use to add scriptability
LoanRequestServer
+ listAll()
+ makeLoan()
AutoLoanInterpreter
+ interpret(script)
AutoLoanScript
+ instructions

Observer
Watching for another object to change state
Use in any event-driven design
Loan
+ RegisterForRepayEvent()
+ RegisterForDefaultEvent()
+ UnregisterForRepayEvent()
+ UnregisterForDefaultEvent()
- FireRepayEvent()
- FireDefaultEvent()
LoanListener
+ OnRepayEvent()
+ OnDefaultEvent()
LoanRequestServer
+ listAll()
+ makeLoan()
AutoLoanInterpreter
+ interpret(script)
+ OnRepayEvent()
+ OnDefaultEvent()
AutoLoanScript
+ instructions

• Template method: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.
• Strategy: Define a family of algorithms. Lets algorithms vary independently from clients that use it.
• Observer: define 1-M dependency between objects (to avoid hidden dependency)

• Visitor: allows a new operation to be defined without changing the classes of the elements on which it operates.

• Framework- are reusable components
• Framework is not an architectural pattern, but rather a skeleton with a collection of plug points that enable it to be adapted to a specific problem domain.

• Design patterns are more abstract than framework
• DP are smaller architectural elements than frameworks.
• DPs are less specialized than frameworks: DPs can be used in any application but frameworks normally have particular application domain its useful for.

• Eg : safehomeassured.com webapp
It must address problems like a) How to provide info about its services and products.
b) How to sell the products and services sub-problem: how to sell via the internet (ecommerce pattern).
a) How to establish internet based monitoring and control of security system etc..

• Pattern name
• Problem: problem its addressing
• Motivation: example of the problem
• Context: describes the environment
• Forces: limitation and constraints
• solution

• Examine the requirements model and develop a problem hierarchy: dividing into smaller subproblems.
• Determine if a reliable pattern language has been developed for the problem domain.
• Beginning with a broad problem determine whether one or more architectural patterns are available for it.

• Using the collaborations provided for the architectural pattern, examine subsystem or component level problems and search for appropriate patterns to addess them.
• Repeat steps 2 through 5 until all broad problems have been addressed.
• If user interface design problems have been isolated search the many user interface desing pattern respositories

• Regardless of its level of abstraction, if a pattern language and/or patterns repository or individual pattern shows promise, compare the problem to be solved against the existing pattern(s) presented.
• Be certain to refine the design as it is derived from patterns using design quality criteria as a guide.

• In your project teams, list some of the limitations and constraints.
• Look for problems/sub-problems.
• Use the pattern template to define any pattern that solves your problem.