Scribd
Upload
77 views8 pages

Design Patterns: Strategy

This document summarizes several design patterns including Strategy, Decorator, Observer, Chain of Responsibility, Singleton, Adapter, Facade, Iterator, Composite, Proxy, and general OOP concepts like abstraction, encapsulation, polymorphism, inheritance vs composition, and the "closed for modification, open for extension" principle. For each pattern, it provides an initial problem example, the solution using that pattern, and a brief description.

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
77 views8 pages

Design Patterns: Strategy

This document summarizes several design patterns including Strategy, Decorator, Observer, Chain of Responsibility, Singleton, Adapter, Facade, Iterator, Composite, Proxy, and general OOP concepts like abstraction, encapsulation, polymorphism, inheritance vs composition, and the "closed for modification, open for extension" principle. For each pattern, it provides an initial problem example, the solution using that pattern, and a brief description.

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/ 8

Design Patterns

- are solutions to programming problems that automatically implement good


design techniques

Strategy
Initial:
abstract class Vehicle {
public void go() {
//prints GO
}
}
class Car extends Vehicle{};
class Helicopter extends Vehicle{//go should print FLY};
class Amphibian extends Vehicle{//go should print GO and DIVE, then again
GO...};

Solution:
interface GoAlgorithm;
class GoByDrivingAlogorithm implements GoAlgorithm;
class GoByFlyingAlogorithm implements GoAlgorithm;

abstract class Vehicle {


private GoAlgorithm goAlgorithm;
public setGoAlgorithm( GoAlgorithm goAlgorithm){}
public void go() {
goAlgorithm.go();
}
}
- the goAlgorithm can be changed at runtime, multiple time
- example of composition "has-a"
- the algorithms code can be shared among other code

Description:
- extract the volatile parts of the code and encapsulate them as
objects
Decorator
class Computer {
public String description() {
return "computer";
}
}

Initial:
class ComputerWithDisk extends Computer{
public String description() {
return "computer with disk";
}
}

class ComputerWithDiskAndDisplay extends ComputerWithDisk{


public String description() {
return "computer with disk and monitor";
}
}

Solution:
abstract class ComputerDecorator extends Computer{
public abstract String description();
}
class ComputerWithDisk extends ComputerDecorator{
public ComputerWithDisk(Computer c) {
this.computer = c;
}
public String description() {
return this.computer.description() + " with disk";
}
}

Description:
• Closed for modification, open for extension principle
• It's called decorator, but a better name would be Augmentor or Extender
because it allows to extend/augment/enhance an existing class
dynamically at runtime, without modifying its core functionality

Observer

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