Description:

• Loose coupling – connecting objects through notifications instead of hard

coding the connection
Chain of Responsibility

Description:
Avoid coupling the sender of a request to its receiver by giving more than one
object a chance to handle the request. Chain the receiving objects and pass the
request along the chain until an object handles it.

Singleton
Description:
- we need only one instance of a specific class to exists in JVM (eg: Registry)

Solution:
- private constructor
- access to the instance will be obtain by using an utility method (getInstance)
- threadsafe stuff may be solved in two ways:
1. make getInstance() syncronized (not recommended – extra complexity)
2. like below – extract creation code outside of getInstance – it will be executed
once by the class loader (if multiple class loaders – then we end up with
multiple singletons)
public class Singleton {
Singleton instance = new Singleton();

private Singleton();

public getInstance() {
return instance;
}
}
- !!!!! cannot subclass a Singleton (since it has a private constructor)

Adapter

Description:
- an intermediate layer between two layers which have different interfarces
- for instance, SecurityService expects UserCredentials class, while the client
layer code only has User class.

Solution:
- UserCredentialsAdapter extends/implements UserCredentials {
// wraps an User object
}
Facade

Description:
- expose a simpler interface for a complicated object – the client doesn't need
to know all that stuff
- example: Computer {
initDisk();
initBios();
initCPU();
etc;
}
Solution:
ComputerFacade {
start() {
computer.initDisk();
etc....
}
}

Iterator

Description:
- allows to access the elements from a collection without knowing the internal
structure of that collection

Composite

Description:
- allows to access the elements in a tree-like hiererchy in a consistent manner
for instance Java Xml DOM, all the branches and leaves are both Node (they are
implementing the same interface)

Proxy

Description:
- provide a surrogate for another objects in order to control the access to it, or
make a remote object look as if it's real one:
ex1: spring creates a dynamic proxy for each service in order to implement
@Transactional behaviour
ex2: for RMI, a proxy that implements the same interface as the remote object
is created locally

OOP

General concepts

Abstraction express real world problem into an object

Encapsulation
• hide the complexity inside objects
• expose a simple interface to the outside world (object's clients – rest of
the code)
• you should encapsulate what changes the most (so the client of the
objects won't be affected by the future changes)
Polymorphism
• ability to write code that can work with different object types and decide
on the actual object type at runtime
• method overriding
• method overloading
Inheritance
• One class can inherit methods and properties from another
Inheritance vs Composition
• "is-a" vs "has-a"
• Design Patterns favors composition over inheritance
• inheritance causes maintenance and extensibility issues over time, it
generates a rigid structure, changes propagates to generations of classes
• what changes more often should be extracted in distinct classes instead
of puting into methods
Closed for Modification, Open for Extension