Design pattern part 2 - structural pattern

Design Pattern
part 2
Jieyi Wu
2017/11/27

GoF
Design Pattern
× Creational Patterns
× Structural
Patterns
× Behavioral
Patterns 1

Structural Pattern
2
× Adapter
× Bridge
× Composite
× Decorator
× Facade
× Flyweight
× Proxy

1.
Adapter
Pattern
• Match interfaces of different classes
3

Roles of the
pattern
× Target
× Adaptee
× Adapter
5

Target
6
interface IMinion {
void DoAttack();
void DoDefense();
}
class Captain implements IMinion {
@Override
public void DoAttack() {
// Do Captain attack.
}
@Override
public void DoDefense() {
// Do Captain defense.
}
}
class Rookie implements IMinion {
@Override
// Do Rookie attack.
}
@Override
// Do Rookie defense.
}
}

Adaptee
7
interface IEnemy {
void DoFire();
void DoGuard();
}
class Boss implements IEnemy {
@Override
public void DoFire() {
// Do something.
}
@Override
public void DoGuard() {
// Do something.
}
}

Adaptor
8
class AdapterMinion implements IMinion {
private final IEnemy iEnemy;
AdapterMinion(IEnemy iEnemy) {
this.iEnemy = iEnemy;
}
@Override
iEnemy.DoFire();
}
@Override
iEnemy.DoGuard();
}
}

Client
9
public class Client {
static public void main(String[] args) {
IMinion rookie = new Rookie();
rookie.DoAttack();
IMinion enemy = new AdapterMinion(new Boss());
enemy.DoAttack();
enemy.DoDefense();
}
}

Pros. & Cons.
✓ Though the adapter, the original code isn’t modified.
✓ Expandable and adaptable, following OCP(Open Close Principle).
✓ For client, clear; For adapter, reusable.
✗ It unnecessarily increases the size of the code as class
inheritance is less used and lot of code is needlessly duplicated
between classes.
11

2.
Bridge
Pattern
12
12
• Separates an object’s interface from its implementation

Roles of the
pattern
× Abstraction
× Refined Abstraction
× Implementor
× Concrete Implementor
14

Abstraction
15
abstract class IMinion {
protected final IWeapon weapon;
protected IMinion(IWeapon weapon) {
this.weapon = weapon;
}
abstract void DoAttack();
}

Refined
Abstraction
16
class Solider extends IMinion {
protected Solider(IWeapon weapon) {
super(weapon);
}
@Override
void DoAttack() {
weapon.Fire();
}
}
class Enemy extends IMinion {
protected Enemy(IWeapon weapon) {
super(weapon);
}
@Override
void DoAttack() {
weapon.Fire();
}
}

Implementor
17
interface IWeapon {
void Fire();
}

Concrete
Implementor
18
class Gun implements IWeapon {
@Override
public void Fire() {
// Shoot operation.
}
}
class Rocket implements IWeapon {
@Override
public void Fire() {
// Fire operation.
}
}

Client
19
IMinion solider = new Solider(new
Rocket());
solider.DoAttack();
IMinion enemy = new Enemy(new Gun());
enemy.DoAttack();
}
}

Pros. & Cons.
✓ Decouple the interface & the implement.
✓ Improving the expandability of the system, but anti SRP.
✓ This pattern is diaphanous for Client and hide the detail.
✗ The system becomes complexity and incomprehensible.
21

3.
Composite
Pattern
• A tree structure of simple and composite objects
22

Roles of the
pattern
× Component
× Leaf
× Composite
24

Component
25
abstract class MenuComponent {
public void add(MenuComponent menuComponent) {
throw new UnsupportedOperationException();
}
public void remove(MenuComponent menuComponent) {
}
public MenuComponent getChild(int i) {
}
public String getName() {
}
public String getDescription() {
}
public double getAttackValue() {
}
public double getDefenseValue() {
}
}

Composite
26
class Menu extends MenuComponent {
private final String name;
private final String description;
private ArrayList components = new ArrayList<MenuComponent>();
Menu(String name, String description) {
this.name = name;
this.description = description;
}
@Override
public void add(MenuComponent menuComponent) {
components.add(menuComponent);
}
@Override
public void remove(MenuComponent menuComponent) {
components.remove(menuComponent);
}
@Override
public MenuComponent getChild(int i) {
return (MenuComponent) components.get(i);
}
@Override
public String getName() {return name;}
@Override
public String getDescription() {return description;}
}

Leaf
27
class MenuItem extends MenuComponent {
private String name;
private String description;
private final double attack;
private final double defense;
MenuItem(String name, String description, double attack,
double defense) {
this.name = name;
this.description = description;
this.attack = attack;
this.defense = defense;
}
@Override
public String getName() {return name;}
@Override
public String getDescription() {return description;}
@Override
public double getAttackValue() {return attack;}
@Override
public double getDefenseValue() {return defense;}
}

Client
28
MenuComponent weaponMenu = new Menu("Weapon", "Hero's weapon menu");
MenuComponent clothMenu = new Menu("Cloth", "Hero's cloth menu");
MenuComponent trouserMenu = new Menu("Trouser", "Hero's armor menu");
MenuComponent all = new Menu("Root menu", "Top");
all.add(weaponMenu);
all.add(clothMenu);
all.add(trouserMenu);
weaponMenu.add(new MenuItem("Sword", "Sword", 10, 0));
weaponMenu.add(new MenuItem("Blade", "Blade", 6, 0));
weaponMenu.add(new MenuItem("Axe", "Axe", 14, 3));
clothMenu.add(new MenuItem("Cloth", "Cloth", 0, 6));
clothMenu.add(new MenuItem("Magic Cloth", "Magic Cloth", 0, 3));
clothMenu.add(new MenuItem("Knight Armor", "Knight Armor", 0, 10));
trouserMenu.add(new MenuItem("Trouser", "Trouser", 0, 10));
trouserMenu.add(new MenuItem("Knight Pants", "Knight Pants", 0, 4));
trouserMenu.add(new MenuItem("Underwear", "Underwear", 0, 8));
}
}

✓ Separating the layer objects and adding a new object easily.
✓ Client can operate leaves & composite object consistently.
✓ Adding a new composite object easily.
✗ Design will be more abstract.
Pros. & Cons.
30

4.
Decorator
Pattern
• Add responsibilities to objects dynamically
31

Roles of the
pattern
× Component
× Concrete Component
× Decorator
× Concrete Decorator
33

Component
34
interface IWeapon {
float attack = 0;
float defense = 0;
float currentAttack();
float currentDefense();
}

Concrete
Component
35
class Sword implements IWeapon {
float attack = 10;
float defense = 0;
@Override
public float currentAttack() {
return attack;
}
@Override
public float currentDefense() {
return defense;
}
}
class Axe implements IWeapon {
float attack = 15;
float defense = 5;
@Override
return attack;
}
@Override
return defense;
}
}

Decorator
36
abstract class Decorator implements IWeapon {
private final IWeapon weapon;
Decorator(IWeapon weapon) {
this.weapon = weapon;
}
@Override
return weapon.currentAttack();
}
@Override
return weapon.currentDefense();
}
}

Concrete
Decorator
37
class ThunderDecorator extends Decorator {
ThunderDecorator(IWeapon weapon) {
super(weapon);
}
@Override
return super.currentAttack() + 15;
}
@Override
return super.currentDefense() + 5;
}
}
class FireDecorator extends Decorator {
FireDecorator(IWeapon weapon) {
super(weapon);
}
@Override
}
@Override
return super.currentDefense();
}
}

Concrete
Decorator
38
class PoisonDecorator extends Decorator {
PoisonDecorator(IWeapon weapon) {
super(weapon);
}
@Override
}
@Override
return super.currentDefense();
}
}

Client
39
IWeapon powerSword =
new FireDecorator(
new PoisonDecorator(new Sword()));
IWeapon magicAxe =
new ThunderDecorator(
new FireDecorator(new Axe()));
}
}

Pros. & Cons.
40
✓ Decorator is more flexible than inheritance.
✓ Decorator can expand the functions of an object.
✓ Decorators of them combined can create various objects.
✓ Following the OCP(Open Closed Principle).
✗ Because when using the decorator pattern, there’re many
objects are created.
✗ It becomes more difficult to debug.

5.
Facade
Pattern
• A single class that represents an entire subsystem
41

Role of the pattern
× Façade
× SubSystems
43

Subsystem
44
class WarriorRoles {}
class MagicianRoles {}
class HunterRoles {}
class KnightRoles {}
class Minions {}

Facade
45
class Stage {
private final WarriorRoles warriorRoles;
private final MagicianRoles magicianRoles;
private final HunterRoles hunterRoles;
private final KnightRoles knightRoles;
private final Minions minions;
Stage(WarriorRoles warriorRoles, MagicianRoles magicianRoles,
HunterRoles hunterRoles, KnightRoles knightRoles,
Minions minions) {
this.warriorRoles = warriorRoles;
this.magicianRoles = magicianRoles;
this.hunterRoles = hunterRoles;
this.knightRoles = knightRoles;
this.minions = minions;
}
public void StageIce() {
warriorRoles.off();
magicianRoles.off();
hunterRoles.on();
knightRoles.off();
minions.quantity(200);
}
public void StageAirCastle() {
warriorRoles.on();
magicianRoles.off();
hunterRoles.off();
knightRoles.on();
minions.quantity(1000);
}
}

Client
46
Stage stage = new Stage(new WarriorRoles(),
new MagicianRoles(),
new HunterRoles(),
new KnightRoles(),
new Minions());
stage.StageIce();
stage.StageAirCastle();
}
}

Pros. & Cons.
✓ Reducing the dependency between the subsystem.
✓ Doesn’t have to care about the subsystem.
✓ Providing only one entry for using the object.
✗ If Client cant constrain to use subsystem well, it will
decrease the flexibility and variability.
✗ Anti OCP(Open Closed Principle).
47

6.
Flyweight
Pattern
• A fine-grained instance used for efficient sharing
48

Role of the pattern
× Flyweight
× Concrete Flyweight
× Flyweight Factory
× Client
50

Flyweight
51
abstract class Flyweight {
abstract void plant(int x, int y);
}

Concrete
Flyweight
52
class Tree extends Flyweight {
private int pX = 0, pY = 0;
private int height = 100;
private double leafQuantity = 0.7f;
private int leafColor = 0x1100ff;
@Override
void plant(int x, int y) {
pX = x;
pY = y;
// Do something.
}
}
class Grass extends Flyweight {
private int pX = 0, pY = 0;
private double leafQuantity = 0.2f;
private int leafColor = 0x0000ff;
@Override
void plant(int x, int y) {
pX = x;
pY = y;
// Do something.
}
}

Flyweight
Factory
53
class FlyweightFactory {
private final HashMap<String, Flyweight> pool =
new HashMap<>();
public Flyweight getFlyweight(String key) {
if (null == pool.get(key)) {
Flyweight object;
if (Objects.equals("grass", key)) {
object = new Grass();
}
else if (Objects.equals("tree", key)) {
object = new Tree();
}
pool.put(key, object);
}
return pool.get(key);
}
public int getFlyweightCount() {
return pool.size();
}
}

Client
54
FlyweightFactory flyweightFactory = new
FlyweightFactory();
flyweightFactory.getFlyweight("tree").plant
(3, 6);
flyweightFactory.getFlyweight("grass").plant
(1, 3);
flyweightFactory.getFlyweight("grass").plant
(2, 6);
flyweightFactory.getFlyweight("tree").plant
(1, 0);
}
}

Pros. & Cons.
✓ Reducing the objects quantity in the memory.
✓ The flyweight’s state is dependent.
✗ The system will be more complexity because separating the
internal & external state.
55

7.
Proxy
Pattern
• An object representing another object
56

Role of the pattern
× Subject
× Proxy
× RealSubject
58

Subject
59
interface IAttack {
void doAttack();
}

Proxy
60
class Proxy implements IAttack {
private final IAttack subject;
public Proxy(IAttack subject) {
this.subject = subject;
}
@Override
public void doAttack() {
// Do professional attack!!!
}
}

RealSubject
61
class Player implements IAttack {
@Override
public void doAttack() {
// Do attack.
}
}

Client
62
IAttack proxy = new Proxy(new Player());
proxy.doAttack();
}
}

Pros. & Cons.
✓ Hide the real subject to avoid the Client uses it directly.
✗ The operation speed will be lower.
✗ For implementing the proxy, there’re many extra works and some
proxy’s implementation is really complexity.
63

Design pattern part 2 - structural pattern

Recommended

More Related Content

What's hot (20)

Similar to Design pattern part 2 - structural pattern (20)

More from Jieyi Wu (8)

Recently uploaded (20)

Design pattern part 2 - structural pattern