Design Pattern - Strategy

http://en.wikipedia.org/wiki/Strategy_pattern

 

Intent:

1. Define a family of algorithms, encapsulate each one, and make them interchangeable.
2. Strategy lets the algorithm vary independently from clients that use it.
3. Policy

Applicability:

1. Classes differ only in their behavior.
2. Different variants of an algorithm.
3. Algorithm uses data that clients shouldn't know about.
4. A class defines many behaviors. 

Structure:

 

Participants:

Strategy 

1. declares an interface common to all supported algorithms. 
2. Context uses this interface to call the algorithm defined by a ConcreteStrategy.

ConcreteStrategy

1. implements the algorithm using the Strategy interface.

Context

1. is configured with a ConcreteStrategy object.
2. maintains a reference to a Strategy object.
3. may define an interface that lets Strategy access its data. 

Overview:

1. Strategy and Context interact to implement the chosen algorithm.
2. A context may pass all data required by the algorithm to the strategy when the algorithm is called.
3. Alternatively, the context can pass itself as an argument to Strategy operations. That lets the strategy call back on the context as required.
4. A context forwards request from its clients to its strategy.
5. Client usually create and pass a ConcreteStrategy object to the context; thereafter, clients interact with the context exclusively.
6. There is often a family of ConcreteStrategy classes for a client to choose from.
7. Families of related algorithms.
8. An alternative to subclassing.
9. Strategies eliminate conditional statements.
10. A choice of implementations.
11. Clients must be aware of different Strategies.
12. Communication overhead between Strategy and Context.
13. Increased number of objects.

Applications:

1. Compositor
2. SimpleCompositor, TeXCompositor, ArrayCompositor
3. Composition

 

Design Pattern - Observer

http://en.wikipedia.org/wiki/Observer_pattern
Intent:

1. Define one-to-many dependency between objects so that when one objects changes state, all its dependents are notified and updated Automatically
2. Dependents, Publish-Subscribe, Model-View

Applicability:

1. When an abstraction has two aspects, one dependent on the other.
2. When a change to one object requires changing others without being coupled.

Structure:

Participants:
Subject

1. knows its observers.
2. any number of Observer objects may observe a subject.
3. provides an interface for attaching and detaching Observer objects.

Observer

1. defines an updating interface for objects that should be notified of changes in a subject.

ConcreteSubject

1. stores state of interest to ConcreteObserver objects.
2. sends a notification to its observers when its state changes.

ConcreteObserver

1. maintains a reference to a ConcreteSubject object.
2. stores state that should stay consistent with the subject's.
3. implementes the Observer updating interface to keep its state consistent with the subject's.

Overview:

1. ConcreteSubject notifies its observers whenever a change occurs that could make its observers' state inconsistent with its own.
2. After being informed of a change in the concrete subject, a ConcreteObserver object may query the subject for information.
3. ConcreteObserver uses this information to reconcile its state with that of the subject.
4. Abstract coupling between Subject and Observer.
5. Support for broadcast communication.
6. Unexpected updates.

Applications:
Document - View architecture

1. Document is responsible for data
2. View is responsible for representing data
3. There can be multiple type of document and view
4. Any view can be interested in tracking changes in any document

Design Pattern - Template Method

http://en.wikipedia.org/wiki/Template_method_pattern

Intent:

1. Define the skeleton of an algorithm in an operation, deferring some steps to subclasses and let subclasses redefine steps of an algorithm without changing the algorithm's structure.

Applicability:

1. To implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behaviro that can vary.
2. Avoid code duplication.
3. To control subclasses exensions.

Structure:

Participants:
AbstractClass

1. defines abstract primitive operations that concrete subclasses define to implement steps of an algorithm.
2. implements a template method defining the skeleton of an algorithm.
3. The template method calls primitive operations as well as operations defined in AbstractClass or those of other objects.

ConcreteClass

1. implements the primitive opreations to carry out subclass-specific steps of the algorithm.

Overview:
ConcreteClass relies on AbstractClass to implement the invariant steps of the algorithm

1. Reuses code
2. Factors common behavior.
3. Realizes "HR" principle.

Applications:

1. Application
2. MyApplication
3. Print Document
4. Manufacture
5. Approve loan:
1. bank history
2. credit score from credit card companies
3. other loan history
4. evaluate assets
5. income in the future
6. Make Pizza
1. take order & money
2. send order to kitchen
3. receive pizza from kitchen
4. deliver pizza
5. clean table

Design Pattern - Singleton

http://en.wikipedia.org/wiki/Singleton_pattern

Intent:

1. Ensure that a class has one and only one instance, and provide a global point of access to the instance

Applicability:

1. Exactly N instance(s) of a class needed:
1. must be accessible to clients
2. a well-known access point
2. When class of sole instance should be extensible

Structure:

Participants:

1. Singleton defines an Instance operation that lets clients access its unique instance.
2. Instance is a class operation (e.e. static member funciton in C++).
3. May be responsible for creating its own unique instance.

Overview:
Client accss a Singleton instance solely through Singleton's instance operation

1. Controlled access to sole instance.
2. Reduced name space.
3. Permoits refinement of operations and representation.
4. Permits a variable number of instances.
5. More flexible than class operations.

Applications:

1. Settings
2. Configuration Data
3. Read-only Data / Cache
4. Print spooler

Design Pattern

What is a design pattern?
Pattern describes a problem which occurs over and over again in a context, and then describes the core of the solution to that problem, in such a way that you can use this core of solution a million times over, without ever using it the same way twice.

• Language-independent strategies for solving common object-oriented design problems
• Common solution to common problem in context and system of forces
• Solution to a narrowly-scoped common technical problem
• Abstraction from a concretion recurring in specific, non-arbitrary contexts
• Successfully recurring best practice that has proven itself in the trneches
• A literary format for capturing wisdom and experience of expert designers, and communicating it to novices.

Why design pattern?
Designing object-oriented code is hard, and designing reusable object-oriented software is even harder - Why?
Patterns enable programmers to recognize a problem and immediately determine the solution without having to stop and analyze the problem first.
Provides a framework for communicating complexities of OO design at a high level of abstraction
Bottom line: Design Productivity

• Solve "real world" problems
• Capture domain expertise
• Document design decisions and rationale
• Reuse wisdowm and experience of practitioners
• Convey expert insight
• Shared vocabulary for problem-solving
• Show more than just the solution
• Teaches OO way!

Object Oriented Pillars

1. Abstraction
• Getting something out
• A process of classifying objects
• E.g. Men, women, car, window
• A class of objects
2. Encapsulation (and Polymorphism)
• Getting something hidden
• Something private that can be access through a public functionYou hide a private implementation inside a public interface
• Poly: One interface, multiple implementation
• Simplifies source code
3. Modularity
• Has the ability to disassemble & assemble back easily (without too much time)
• Can work on module parallel
• Each module less independent
4. Hierarchy
• Inheritance
• Referential - one refer to one