Contents

1. Singelton : ......................................................................................... 2
1.1. Intro : ........................................................................................... 2
1.2. Structure: ..................................................................................... 2
1.3. Implementation: ........................................................................... 3
2. Composite : ....................................................................................... 3
2.1. Intro : ........................................................................................... 3
2.2. Structure : .................................................................................... 4
2.3. Implementation : .......................................................................... 5
2.4. Use cases : ................................................................................... 5
3. Observer : .......................................................................................... 6
3.1. Intro : ........................................................................................... 6
3.2. Structure : .................................................................................... 6
3.3. Implementation : .......................................................................... 7
3.4. Use cases: .................................................................................... 8
4. Strategy : ........................................................................................... 9
4.1. Intro : ........................................................................................... 9
4.2. Structure : .................................................................................... 9
4.3. Implementation : ........................................................................ 10
4.4. Use cases : ................................................................................. 10
5. MVC : ............................................................................................. 11
5.1. Intro : ......................................................................................... 11
5.1.1. Model : ................................................................................ 11
5.1.2. View : .................................................................................. 11
5.1.3. Controler : ........................................................................... 11
5.2. Structure .................................................................................... 11
Patrons de conception :

1. Singelton :

1.1. Intro :
This pattern involves a single class which is
responsible to create an object while making sure that only
single object which can be accessed directly without need
to instantiate the object of the class.
1.2. Structure:

 The singleton class declares the static method

(getInstance) that return the same instance of its
own class.
 The singleton’s constructor should be hidden from
the client code. Calling getInstance method should
be the only way of getting the Singleton object.
 1.3. Implementation:

 Add a private static field to the class for storing

the singleton instance
 Declare a public static creation method for getting
the singleton instance
 Implement “Lazy Initialization” inside the static
method. It should create a new object on its first
call and put it into the static field. The method
should always return that instance on all
subsequent calls.
 Make the constructor of the class private. The
static method of the class will still be able to call
the constructor, but not the other objects.
 Go over the client code and replace all direct calls
to the singleton’s constructor with calls to its static
creation method.

2. Composite :

2.1. Intro :
The composite design pattern has a primary
goal of combining objects and classes into a
bigger structure while keeping the structure as
abstract as it possibly can be.
2.2. Structure :

 The Component interface describes operations

that are common to both simple and complex
elements of the tree.
 The Leaf is a basic element of a tree that doesn’t
have sub-elements.
- Usually, leaf components end up doing most of
the real work, since they don’t have anyone to
delegate the work to.
 The Container (aka composite) is an element that
has sub-elements: leaves or other containers. A
container doesn’t know the concrete classes of its
children. It works with all sub-elements only via
the component interface.
- Upon receiving a request, a container delegates
the work to its sub-elements, processes
intermediate results and then returns the final
result to the client.
 The Client works with all elements through the
component interface. As a result, the client can
work in the same way with both simple or
complex elements of the tree.
2.3. Implementation :

 Make sure that the core model of your app can be

represented as a tree structure. Try to break it
down into simple elements and containers.
Remember that containers must be able to contain
both simple elements and other containers.
 Declare the component interface with a list of
methods that make sense for both simple and
complex components.
 Create a leaf class to represent simple elements. A
program may have multiple different leaf classes.
 Create a container class to represent complex
elements. In this class, provide an array field for
storing references to sub-elements. The array must
be able to store both leaves and containers, so
make sure it’s declared with the component
interface type.
- While implementing the methods of the
component interface, remember that a container
is supposed to be delegating most of the work
to sub-elements.
 Finally, define the methods for adding and
removal of child elements in the container.
2.4. Use cases :
 Recurring design issues.
 File systems, we could classify them into
categories, as such as individual files would be the
leaves and the folders than contain the files or
other folders, should be the root.
 Menu bar that contains multiple roots.
3. Observer :
3.1. Intro :
This design pattern makes sure to create a
dependency between the class (often called Concrete
Subject) and the interface (called observer).
3.2. Structure :

In our example, Subscriber is observer.

 The Publisher issues events of interest to other
objects. These events occur when the publisher
changes its state or executes some behaviors.
Publishers contain a subscription infrastructure
that lets new subscribers join and current
subscribers leave the list.
 When a new event happens, the publisher goes
over the subscription list and calls the notification
method declared in the subscriber interface on
each subscriber object.
 The Subscriber interface declares the notification
interface. In most cases, it consists of a single
update method. The method may have several
parameters that let the publisher pass some event
details along with the update.
 Concrete Subscribers perform some actions in
response to notifications issued by the publisher.
 All of these classes must implement the same
interface so the publisher isn’t coupled to concrete
classes.
 Usually, subscribers need some contextual
information to handle the update correctly. For
this reason, publishers often pass some context
data as arguments of the notification method. The
publisher can pass itself as an argument, letting
subscriber fetch any required data directly.
 The Client creates publisher and subscriber
objects separately and then registers subscribers
for publisher updates.

3.3. Implementation :
 Look over your business logic and try to break it
down into two parts: the core functionality,
independent from other code, will act as the
publisher; the rest will turn into a set of subscriber
classes.
 Declare the subscriber interface. At a bare
minimum, it should declare a single update
method.
 Declare the publisher interface and describe a pair
of methods for adding a subscriber object to and
removing it from the list. Remember that
publishers must work with subscribers only via
the subscriber interface.
 Decide where to put the actual subscription list
and the implementation of subscription methods.
Usually, this code looks the same for all types of
publishers, so the obvious place to put it is in an
abstract class derived directly from the publisher
interface. Concrete publishers extend that class,
inheriting the subscription behavior.
 - However, if you’re applying the pattern to an
existing class hierarchy, consider an approach
based on composition: put the subscription
logic into a separate object, and make all real
publishers use it.
 Create concrete publisher classes. Each time
something important happens inside a publisher, it
must notify all its subscribers.
 Implement the update notification methods in
concrete subscriber classes. Most subscribers
would need some context data about the event. It
can be passed as an argument of the notification
method.
- But there’s another option. Upon receiving a
notification, the subscriber can fetch any data
directly from the notification. In this case, the
publisher must pass itself via the update
method. The less flexible option is to link a
publisher to the subscriber permanently via the
constructor.
 The client must create all necessary subscribers
and register them with proper publishers.
3.4. Use cases:
 Whenever we’re interested in the state of an object
and want to get notified whenever there is any
change.
4. Strategy :

4.1. Intro :
This design pattern makes sure to adopt the
behavior and the algorithms of an object according to
the needs, without necessarily changing the
interactions of the object with the clients.

4.2. Structure :

 The Context maintains a reference to one of the

concrete strategies and communicates with this
object only via the strategy interface.
 The Strategy interface is common to all concrete
strategies. It declares a method the context uses to
execute a strategy.
 Concrete Strategies implement different variations
of an algorithm the context uses.
 The context calls the execution method on the
linked strategy object each time it needs to run the
 algorithm. The context doesn’t know what type of
strategy it works with or how the algorithm is
executed.
 The Client creates a specific strategy object and
passes it to the context. The context exposes a
setter which lets clients replace the strategy
associated with the context at runtime.

4.3. Implementation :

 In the context class, identify an algorithm that’s

prone to frequent changes. It may also be a
massive conditional that selects and executes a
variant of the same algorithm at runtime.
 Declare the strategy interface common to all
variants of the algorithm.
 One by one, extract all algorithms into their own
classes. They should all implement the strategy
interface.
 In the context class, add a field for storing a
reference to a strategy object. Provide a setter for
replacing values of that field. The context should
work with the strategy object only via the strategy
interface. The context may define an interface
which lets the strategy access its data.
 Clients of the context must associate it with a
suitable strategy that matches the way they expect
the context to perform its primary job.

4.4. Use cases :

 Dependency inversion principale (DIP) in SOLID

5. MVC :
5.1. Intro :
This design pattern is a composition of 3
patterns, composite observer and strategy, its main
purpose is to decompose everything into 3 main
categories:
5.1.1. Model :
Takes charge of the data.
5.1.2. View :
Takes charge of the display of the data.
5.1.3. Controler :
Takes charge of the treatment that happens to
the data (modifications…etc).
5.2. Structure