# OOAD Lab 15 (06/01)
###### tags: `OOAD`

---

[TOC]

---

## 15. Design Pattern 2
### Factory Pattern
- **Design Principle**:
- ***"Program to an interface not an implementation"***
- **Design Principle**:
- ***"Classes should be open for extension, but closed for modification"***
- You do not need to open several places and change code as new concrete classes are added
- **Example**:
- You try to use polymorphism but **new** force you to write such kind of code:
- `Duck duck = new MallardDuck();`
- ---> **Program to implementation**
- It will be **reopened and examined** when the code should be changed
- **New** operators involves with **concrete object**
- **Worse**: lots of **concrete classes** (especially **kernel code**)
- **Better**: with **interfaces** and using **polymorphism**
- ---> **Identify the aspects that vary and separate them from what stays the same**
- ---> **Decoupling** and **Centralizing**
- **Simple Static Factory**:
- **Centralizing new operations in a static method** inside a simple factory class
- **Factory Pattern**:
> **encapsulates object creation by letting subclasses decide which objects to create**
- Factory method lets a class **defer instantiation to subclasses**
- The **factories** can be extracted and extends abstracts
- Advantage:
- I you add additional products or change a product's implementation. It will not affect your Creator (because the Creator is not tightly coupled to any ConcreteProduct).
- **Design Principle**:
- **The Dependency Inverse Principle (DIP)**:
- ***"Depend upon abstractions. Do not depend upon concrete classes."***
- High level components should not depend on our low-level components
- **Not to depend on concrete classes**
- Guidelines:
- **No variables** should **hold a reference to a concrete class**
- **No class** should **derive from a concrete class**
- **No method** should **override an implemented method of any of its base classes**

### Decorator Pattern
- **Design Principle**:
- ***"Classes should be open for extension, but closed for modification"***
- **OO**: ***"Experience! Experience! Experience!"***
- **Decorator Pattern**:
> **The Decorator Pattern attaches additional responsibilities to an object dynamically.**
> **Decorators provide a flexible alternative to subclassing for extending functionality.**
> 
- Revisit the problem again:
- we get **class explosions**, rigid designs, or we add functionality to the base class that isn’t appropriate for some of the subclasses.
- **Constructing new Component from Decorator classes dynamically**

        Component comp = new ConcreteComponent();
        comp = new ConcreteDecoratorA(comp);
        comp = new ConcreteDecoratorB(comp);
        comp.method();

- **Dark side**:
- You can usually **insert decorators transparently** and the client never has to know it’s dealing with a decorator
- Example IRL: **Java I/O**

### Model-View-Control Architecture
- **One of the earliest design patterns**
- **GUI Change**:
- **GUI is the most unstable components in software**
- **Wrong**:
- **Computation logic is mixed with UI code**
- ---> It violates the **open for extension and closed for modification** principle.
- **Model-View-Control (MVC)**: The king pattern
- **Model** ***(Observer)***: the **computation** model (computation logic handler)
- **Not to depend on GUI**
- **View** ***(Composite)***: the entity that **render** the data into visualization objects.
- **Controller** ***(Strategy)***: the entity that deals with **user events**
- interpret user’s actions and decide how to interact with model
- When to use:
- Change to different GUI platform
- To determine what is model