The document discusses various software design patterns including Strategy, State, Bridge, Composite, Flyweight, Interpreter, Decorator, Chain of Responsibility, Facade, Adapter, Proxy, Command, Memento, Iterator, Mediator, Observer, Template Method, Visitor, Factory Method, Prototype, Abstract Factory, Builder, and Singleton. For each pattern, it provides a brief definition and example use cases. It also includes links to Wikipedia pages with more detailed explanations of each design pattern.

1. Miriam Ruiz <miriam@debian.org>
UML Design Class Diagrams

2. 2 / 24
Strategy
http://en.wikipedia.org/wiki/Strategy_pattern
The Strategy Pattern (also known as the Policy Pattern) is a software design
pattern that enables an algorithm's behavior to be selected at runtime. The
strategy pattern defines a family of algorithms, encapsulates each algorithm,
and makes the algorithms interchangeable within that family. Strategy lets the
algorithm vary independently from clients that use it.

3. 3 / 24
State
The State Pattern, which closely resembles Strategy Pattern, is a behavioral
software design pattern, also known as the objects for states pattern. This
pattern is used in computer programming to encapsulate varying behavior for
the same routine based on an object's state object. This can be a cleaner way
for an object to change its behavior at runtime without resorting to large
monolithic conditional statements.
http://en.wikipedia.org/wiki/State_pattern

4. 4 / 24
Bridge
The Bridge Pattern is meant to "decouple an abstraction from its implementation
so that the two can vary independently". The bridge uses encapsulation,
aggregation, and can use inheritance to separate responsibilities into different
classes. The Bridge Pattern is useful when both the class as well as what it
does vary often. The class itself can be thought of as the implementation and
what the class can do as the abstraction. The bridge pattern can also be
thought of as two layers of abstraction. The Bridge Pattern is often confused
with the Adapter Pattern. In fact, the Bridge Pattern is often implemented using
the Class Adapter Pattern,
http://en.wikipedia.org/wiki/Bridge_pattern

5. 5 / 24
Composite
The Composite Pattern is a partitioning design pattern. The composite pattern
describes that a group of objects are to be treated in the same way as a single
instance of an object. The intent of a composite is to "compose" objects into tree
structures to represent part-whole hierarchies. Implementing the Composite
Pattern lets clients treat individual objects and compositions uniformly.
http://en.wikipedia.org/wiki/Composite_pattern

6. 6 / 24
Flyweight
A flyweight is an object that minimizes memory use by sharing as much data as
possible with other similar objects. It is a way to use objects in large numbers
when a simple repeated representation would use an unacceptable amount of
memory. Often some parts of the object state can be shared, and it is common
practice to hold them in external data structures and pass them to the flyweight
objects temporarily when they are used. A classic example is the data structures
for graphical representation of characters in a word processor. For every
character there might be a reference to a flyweight glyph object shared by every
instance of the same character in the document. Only the position of each
character (in the document and/or the page) would need to be stored internally.
http://en.wikipedia.org/wiki/Flyweight_pattern

7. 7 / 24
Interpreter
http://en.wikipedia.org/wiki/Interpreter_pattern
The Interpreter Pattern is a design pattern that specifies how to evaluate
sentences in a language. The basic idea is to have a class for each symbol
(terminal or nonterminal) in a specialized computer language. The syntax tree of
a sentence in the language is an instance of the composite pattern and is used
to evaluate (interpret) the sentence. Uses for the Interpreter pattern: specialized
database query languages such as SQL; specialized computer languages which
are often used to describe communication protocols; most general-purpose
computer languages actually incorporate several specialized languages.

8. 8 / 24
Decorator
http://en.wikipedia.org/wiki/Decorator_pattern
The Decorator Pattern (also known as Wrapper, an alternative naming shared
with the Adapter Pattern) is a design pattern that allows behavior to be added to
an individual object, either statically or dynamically, without affecting the
behavior of other objects from the same class.

9. 9 / 24
Chain of Responsibility
http://en.wikipedia.org/wiki/Chain_of_responsibility_pattern
The Chain-Of-Responsibility Pattern is a design pattern consisting of a source
of command objects and a series of processing objects. Each processing object
contains logic that defines the types of command objects that it can handle. The
rest are passed to the next processing object in the chain. A mechanism also
exists for adding new processing objects to the end of this chain. This pattern
promotes the idea of loose coupling, which is considered a programming best
practice.

10. 10 / 24
Facade
http://en.wikipedia.org/wiki/Facade_pattern
The Facade Pattern (or Façade Pattern) is a software design pattern commonly
used with object-oriented programming. The name is by analogy to an
architectural facade. A facade is an object that provides a simplified interface to
a larger body of code, such as a class library. A facade can: make a software
library easier to use, understand and test, since the facade has convenient
methods for common tasks; make the library more readable, for the same
reason; reduce dependencies of outside code on the inner workings of a library,
since most code uses the facade, thus allowing more flexibility in developing the
system; wrap a poorly designed collection of APIs with a single well-designed
API (as per task needs).

11. 11 / 24
Adapter
http://en.wikipedia.org/wiki/Adapter_pattern
The Adapter Pattern is a software design pattern that allows the interface of an
existing class to be used from another interface. It is often used to make
existing classes work with others without modifying their source code.

12. 12 / 24
Proxy
http://en.wikipedia.org/wiki/Proxy_pattern
A Proxy, in its most general form, is a class functioning as an interface to
something else. The proxy could interface to anything: a network connection, a
large object in memory, a file, or some other resource that is expensive or
impossible to duplicate. A well-known example of the Proxy Pattern is a
reference counting pointer object. In situations where multiple copies of a
complex object must exist, the proxy pattern can be adapted to incorporate the
flyweight pattern in order to reduce the application's memory footprint. Typically,
one instance of the complex object and multiple proxy objects are created, all of
which contain a reference to the single original complex object. Any operations
performed on the proxies are forwarded to the original object. Once all
instances of the proxy are out of scope, the complex object's memory may be
deallocated.

13. 13 / 24
Command
http://en.wikipedia.org/wiki/Command_pattern
The Command Pattern is a behavioral design pattern in which an object is used
to represent and encapsulate all the information needed to call a method at a
later time. Using command objects makes it easier to construct general
components that need to delegate, sequence or execute method calls at a time
of their choosing without the need to know the class of the method or the
method parameters.

14. 14 / 24
Memento
http://en.wikipedia.org/wiki/Memento_pattern
The Memento Pattern is a software design pattern that provides the ability to
restore an object to its previous state (undo via rollback). The originator is
some object that has an internal state. The caretaker is going to do something
to the originator, but wants to be able to undo the change. The caretaker first
asks the originator for a memento object. Then it does whatever operation (or
sequence of operations) it was going to do. To roll back to the state before the
operations, it returns the memento object to the originator. The memento object
itself is an opaque object (one which the caretaker cannot, or should not,
change). Classic examples of the memento pattern include the seed of a
pseudorandom number generator (it will always produce the same sequence
thereafter when initialized with the seed state) and the state in a finite state
machine.

15. 15 / 24
Iterator
http://en.wikipedia.org/wiki/Iterator_pattern
The Iterator Pattern is a design pattern in which an iterator is used to traverse a
container and access the container's elements. The iterator pattern decouples
algorithms from containers; in some cases, algorithms are necessarily
container-specific and thus cannot be decoupled. For example, the hypothetical
algorithm SearchForElement can be implemented generally using a specified
type of iterator rather than implementing it as a container-specific algorithm.
This allows SearchForElement to be used on any container that supports the
required type of iterator.

16. 16 / 24
Mediator
http://en.wikipedia.org/wiki/Mediator_pattern
The Mediator Pattern defines an object that encapsulates how a set of objects
interact. This pattern is considered to be a behavioral pattern due to the way it
can alter the program's running behavior. With the mediator pattern,
communication between objects is encapsulated with a mediator object. Objects
no longer communicate directly with each other, but instead communicate
through the mediator. This reduces the dependencies between communicating
objects, thereby lowering the coupling.

17. 17 / 24
Observer
http://en.wikipedia.org/wiki/Observer_pattern
The Observer Pattern 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. The Observer
pattern is also a key part in the familiar Model View Controller (MVC)
architectural pattern. In fact the observer pattern was first implemented in
Smalltalk's MVC based user interface framework. The Observer Pattern is
implemented in numerous programming libraries and systems, including almost
all GUI toolkits.

18. 18 / 24
Template Method
http://en.wikipedia.org/wiki/Template_method_pattern
The Template Method Pattern is a behavioral design pattern that defines the
program skeleton of an algorithm in a method, called template method, which
defers some steps to subclasses. It lets one redefine certain steps of an
algorithm without changing the algorithm's structure. This use of "template" is
unrelated to C++ templates. In the Template Method of this design pattern, one
or more algorithm steps can be overridden by subclasses to allow differing
behaviors while ensuring that the overarching algorithm is still followed.

19. 19 / 24
Visitor
http://en.wikipedia.org/wiki/Visitor_pattern
The Visitor Pattern is a way of separating an algorithm from an object structure
on which it operates. A practical result of this separation is the ability to add new
operations to existing object structures without modifying those structures. It is
one way to follow the open/closed principle. In essence, the visitor allows one to
add new virtual functions to a family of classes without modifying the classes
themselves; instead, one creates a visitor class that implements all of the
appropriate specializations of the virtual function. The visitor takes the instance
reference as input, and implements the goal through double dispatch.

20. 20 / 24
Factory Method
http://en.wikipedia.org/wiki/Factory_method_pattern
The Factory Method pattern is a creational pattern which uses factory methods
to deal with the problem of creating objects without specifying the exact class of
object that will be created. This is done by creating objects via a factory method,
which is either specified in an interface (abstract class) and implemented in
implementing classes (concrete classes); or implemented in a base class, which
can be overridden when inherited in derived classes; rather than by a
constructor.

21. 21 / 24
Prototype
http://en.wikipedia.org/wiki/Prototype_pattern
The Prototype Pattern is a creational design pattern in software development.
This pattern is used to avoid subclasses of an object creator in the client
application, like the abstract factory pattern does, and to avoid the inherent cost
of creating a new object in the standard way (using the 'new' keyword) when it is
prohibitively expensive. To implement the pattern, an abstract base class that
specifies a pure virtual clone() method is declared, and any class that needs a
"polymorphic constructor" capability derives itself from the abstract base class.
The client calls the clone() method on the prototype, calls a factory method with
a parameter designating the particular concrete derived class desired, or
invokes the clone() method through some mechanism provided by another
design pattern.

22. 22 / 24
Abstract Factory
http://en.wikipedia.org/wiki/Abstract_factory_pattern
The Abstract Factory Pattern provides a way to encapsulate a group of
individual factories that have a common theme without specifying their concrete
classes. In normal usage, the client software creates a concrete implementation
of the Abstract Factory and then uses the generic interface of the factory to
create the concrete objects that are part of the theme. The client doesn't know
(or care) which concrete objects it gets from each of these internal factories,
since it uses only the generic interfaces of their products. This pattern separates
the details of implementation of a set of objects from their general usage and
relies on object composition, as object creation is implemented in methods
exposed in the Factory interface.

23. 23 / 24
Builder
http://en.wikipedia.org/wiki/Builder_pattern
The Builder Pattern is an object creation software design pattern. Unlike the
Abstract Factory Pattern and the Factory Method Pattern whose intention is to
enable polymorphism, the intention of the builder pattern is to find a solution to
the telescoping constructor anti-pattern. The telescoping constructor anti-pattern
occurs when the increase of object constructor parameter combination leads to
an exponential list of constructors. Instead of using numerous constructors, the
builder pattern uses another object, a builder, that receives each initialization
parameter step by step and then returns the resulting constructed object at
once. The builder pattern has another benefit: it can be used for objects that
contain flat data (html code, SQL query, X.509 certificate...), that is, data that
cannot be edited step by step and must be edited at once.

24. 24 / 24
Singleton
http://en.wikipedia.org/wiki/Singleton_pattern
The Singleton Pattern is a design pattern that restricts the instantiation of a
class to one object. This is useful when exactly one object is needed to
coordinate actions across the system. The concept is sometimes generalized to
systems that operate more efficiently when only one object exists, or that restrict
the instantiation to a certain number of objects. The term comes from the
mathematical concept of a singleton. There is criticism of the use of the
singleton pattern, as some consider it an anti-pattern, judging that it is overused,
introduces unnecessary restrictions in situations where a sole instance of a
class is not actually required, and introduces global state into an application. In
C++ it also serves to isolate from the unpredictability of the order of dynamic
initialization, returning control to the programmer.