Oo

Front 1

Strategy Pattern

Back 1

Intent:

Allow algorithms to be selected at runtime, by defining a family of algorithms, encapsulating each algorithm, and making the algorithms interchangeable within that family

Context:

Implementation of a family of algorithms

Problem: This pattern addresses situations where there are multiple ways of doing the same kind of thing, but with different kinds of input, output, or runtime characteristics and the choice of which way to do it has to be made at runtime

Front 2

Strategy Pattern

Back 2

Front 3

Strategy Pattern

Back 3

Consequences:

- In the strategy hierarchy, inheritance can help factor out common functionality of the algorithms, especially if combined with the Template Method pattern.

-Encapsulating the algorithm in separate Strategy classes lets you vary the algorithm independently of its context, making it easier to switch, understand, and extend.

-Strategies can eliminate conditional statements.

Front 4

Observer Pattern

Back 4

Intent:

Simplify dependencies between objects when state changes are a primary concern.

Context:

There are multiple possible contexts, but the most common is graphical user interfaces, where multiple displays need to show state information about the same objects. However, in general, the context could be any system where state changes need to be monitored by multiple components.

Problem:

The system includes a objects of certain classes (i.e., subjects) whose state changes must known by objects of other classes (i.e., observers). The subjects and the observers may be organized into sub-classes.

Front 5

Observer Pattern

Back 5

Front 6

Observer Pattern

Back 6

Consequences:

-Lower coupling between subjects and observers

- Support a multicast-style of communication, where the sender (subject) does not need to know about or depend on the specific receivers (concrete observers)

-Observers can be completely independent of each other, even though they may deal with the same subject object

Front 7

Decorator Pattern

Back 7

Intent:

Attach any combination of additional responsibilities to an object at run time

Context: Any system where combinations of features are possible and there is a potential for an explosion in the number of sub classes

Problem: The actors of a system need to add or remove features to an object dynamically

Front 8

Decorator Pattern

Back 8

Front 9

Decorator Pattern

Back 9

Consequences:

-More flexibility that static inheritance

-Avoid explosion of sub-classes

-More testable than one bloated class

-Lots of little objects linked in a delegation chain that represent one real-world object

-As the components interface becomes more complex, the complexity of the

Front 10

Simply Factory Idiom

Back 10

Intent:

Reduce coupling with concrete constructors

Context: Any situation where a system needs to create instances from a hierarchy of classes

Problem: A component needs to create a specific kind of object from a class hierarchy, called the product class hierarchy, but the choice of which concrete product subclass to instantiate has to be made at runtime.