Design Patterns

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

2. <Patterns> • 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?

3. Design Patterns • 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)

4. Design Patterns • 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.

5. Flight ticket example • 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.

6. Characteristics of an effective design Patterns • 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).

7. Design Patterns • 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.

8. Design Patterns • Traffic example • Design patterns span a broad spectrum of abstraction and application: • Architectural pattern • Data patterns: data modeling solutions. • Component patterns/design patterns: • Interface design patterns. • Webapp patterns.

9. Object oriented design 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.

10. Example system • Kiva system to connect lenders with borrowers • How could we useDPs to implementKiva? • How could we useDPs to implementa better Kiva???

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

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

13. Facade PaymentProcessor + pay($ amount) 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 CreditCardPaymentAdapter + pay($ amount) .netCharge component + issueCharge($ amount, timeout) GatewayProxy ComponentLicense GatewayRequest Remote server RequestConfiguration + timeout + URL + HTTP client certificate

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

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

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

17. Other patterns • 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)

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

19. Pattern vs Framework • 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.

20. Pattern vs Framework • 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.

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

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

23. Design task steps • Examine the requirements model and develop a problem hierarchy: dividing into smaller sub-problems. • 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.

24. Design task steps • 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

25. Design task steps • 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.

26. Design task • 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.