---
# System prepended metadata

title: OOAD Lab 15 (06/01)
tags: [OOAD]

---

# 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**
    ![](https://hackmd.io/_uploads/rkbVX_V8n.png)
    - 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.**
    > ![](https://hackmd.io/_uploads/SkbQj_4I3.png)
    - 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**
        ```java
        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**
    ![](https://hackmd.io/_uploads/By1jhd4Uh.png)
    ![](https://hackmd.io/_uploads/SJsWTdVI3.png)

### 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
    ![](https://hackmd.io/_uploads/SkkhgF4Ih.png)
    - **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

