Scribd
Upload
65 views6 pages

Loose Coupling - Connecting Objects Through Notifications Instead of Hard Coding The Connection

This document describes several design patterns: - Loose coupling connects objects through notifications instead of hard coding. - Chain of Responsibility avoids coupling a request sender to its receiver by allowing multiple objects to handle a request by passing it along a chain. - Singleton ensures only one instance of a class exists in the Java virtual machine. It uses a private constructor and static getInstance method. - Adapter provides an intermediate layer between classes that have different interfaces. - Facade exposes a simpler interface to a more complex underlying object. - Iterator allows accessing elements in a collection without knowing its structure. - Composite allows accessing elements in a tree hierarchy consistently via the same interface. - Proxy provides a surrogate for

Uploaded by

AdinaAndreeaDreve
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
65 views6 pages

Loose Coupling - Connecting Objects Through Notifications Instead of Hard Coding The Connection

This document describes several design patterns: - Loose coupling connects objects through notifications instead of hard coding. - Chain of Responsibility avoids coupling a request sender to its receiver by allowing multiple objects to handle a request by passing it along a chain. - Singleton ensures only one instance of a class exists in the Java virtual machine. It uses a private constructor and static getInstance method. - Adapter provides an intermediate layer between classes that have different interfaces. - Facade exposes a simpler interface to a more complex underlying object. - Iterator allows accessing elements in a collection without knowing its structure. - Composite allows accessing elements in a tree hierarchy consistently via the same interface. - Proxy provides a surrogate for

Uploaded by

AdinaAndreeaDreve
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
You are on page 1/ 6

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

You might also like