## 필요성

집에서 나만의 영화관을 만든다고 가정해보자.
편-안하게 영화를 보고싶지만, 영화 보기 전 선행되어야 할 일들이 많다.

```java:HomeTheater.java
public class HomeTheater {
 public static void main(String[] args) {
 ...
 // 팝콘을 튀기고
 popper.on(); 
 popper.pop();
 // 조명을 낮추고
 lights.dim(10); 
 // 스크린을 내리고
 screen.down();
 // 빔 프로젝터를 설정하고
 projector.on();
 projector.setInput(dvd);
 projector.wideScreenMode();
 // 앱프에 영화를 넣고
 amp.on();
 amp.setDvd(dvd);
 amp.setSurroundSound();
 amp.setVolume(5);
 // 영화 실행...
 dvd.on();
 dvd.play(movie);
 }
}
```

이런 일련의 과정을 클라이언트에게 할당하면, 개발자 입장에선 피곤할 뿐만 아니라, 장치의 메서드에 변화가 생기면 클라이언트가 해당 부분을 수정해야 한다는 단점이 있다.

## Facade Pattern

Facade 디자인 패턴은 **단일화된 인터페이스로 서브 시스템을 다루는 패턴**으로, 위의 일련의 과정을 클라이언트에게 맡기는 것이 아닌, 하나의 인터페이스로 묶고, 그 인터페이스만 클라이언트에게 제공하는 것이다.

```java:HomeTheaterFacade.java
public class HomeTheaterFacade {
 Amplifire amp;
 DvdPlayer dvd;
 Projector projector;
 ...

 public HomeTheaterFacade (Amplifire amp, ...) {
 this.amp = amp;
 ... 
 }

 public void watchMovie(String movie) {
 // 팝콘을 튀기고
 popper.on(); 
 popper.pop();
 // 조명을 낮추고
 lights.dim(10); 
 // 스크린을 내리고
 screen.down();
 // 빔 프로젝터를 설정하고
 projector.on();
 projector.setInput(dvd);
 projector.wideScreenMode();
 // 앱프에 영화를 넣고
 amp.on();
 amp.setDvd(dvd);
 amp.setSurroundSound();
 amp.setVolume(5);
 // 영화 실행...
 dvd.on();
 dvd.play(movie);
 }
}
```

```java:HomeTheater.java
public class HomeTheater {
 public static void main(String[] args) {
 ...

 HomeTheaterFacade homeTheater = new HomeTheaterFacade(...);

 homeTheater.watchMovie("movie");
 }
}
```

일련의 모든 과정을 Facade에게 일임하여 클라이언트는 Facade를 이용해 나름 매크로 기능을 이용할 수 있다.

<tip>
 눈여겨 봐야 할 디자인 원칙: **직접적인 친구와만 대화하라**
 
 객체의 메서드는 다음과 같은 경우에만 호출하는 것이 바람직하다.
 1. 객체 자신의 멤버 메서드를 호출
 2. 인자로서 넘어온 객체의 메서드를 호출
 3. 메서드 내부에서 생성된 객체의 메서드를 호출
 4. 객체의 멤버변수로 저장된 객체의 메서드 호출

 예를 들어보자.
 아래와 같은 경우는 부적절한 경우이다.

 ```java:.java
 public float getTemp() {
 Thermometer thermometer = station.getThermometer();
 return thermometer.getTemperature();
 }
 ```

 thermometer가 getTemp() **메서드 내부에서 생성되지 않았**는데, 해당 객체의 getTemperature() 메서드를 호출했기 때문이다.
 
 대신에 아래와 같이 하는 것이 바람직하다.

 ```java:.java
 public float getTemp() {
 return station.getTemperature();
 }
 ```

 
 정리하면, 객체의 메서드를 호출할 때에는 객체간의 인과관계가 명확한 상황에서만 호출하라는 뜻이다.
</tip>

Facade 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Facade Pattern

## 필요성

Composite pattern을 사용하면서 동적으로 어떤 기능을 추가해야 하는 경우가 있다.

이 경우 컴포넌트가 visitor의 접근 수락(accept) 하여 기능을 수행하는 패턴을 Visitor Pattern 라고 한다.

## Visitor Pattern

예시를 위해 java코드로 html 파일을 작성하는 코드를 구현한다고 가정해보자.

```java:VisitorPattern.java
public interface Element {
 public void accept(Visitor visitor);
}

public interface Visitor {
 public void visit(HtmlElement element);
 public void visit(HtmlParentElement parentElement);
}
```

우선 모든 `방문 대상의 클래스`를 하나의 Element 인터페이스로 묶기 위해 인터페이스를 만든다.
또한, 방문하여 `수정을 가할 클래스`는 Visitor 인터페이스로 묶기게 되는데, 해당 클래스의 visit 메서드는 모든 방문 대상의 구현 클래스를 방문할 수 있어야 한다.

```java:HtmlTag.java
public abstract class HtmlTag implements Element {
 public String getTagName() {
 throw new UnsupportedOperationException();
 }
 public void setTagBody(String tagBody) {
 throw new UnsupportedOperationException();
 }
 // ...
}
```

`구현할 방문 대상의 클래스`는 모두 HtmlTag를 상속받게 되는데, 이 부분은 Composite pattern과 동일하다.

```java:HtmlElement.java
public class HtmlElement extends HtmlTag {
 private String tagName;
 private String startTag;
 private String tagBody;

 public HtmlElement(String tagName) {
 this.tagName = tagName;
 this.tagName = '';
 }

 @override
 public String getTagName() {
 return tagName;
 }
 ...
 @override
 public void accept(Visitor visitor) {
 visitor.visit(this);
 }
}
```

```java:HtmlParentElement.java
public class HtmlParentElement extends HtmlTag {
 private String tagName;
 private String startTag;
 private List<HtmlTag> childrenTag;

 public HtmlParentElement(String tagName) {
 this.tagName = tagName;
 this.childrenTag = new ArrayList<HtmlTag>();
 }

 @override
 public String getTagName() {
 return tagName;
 }
 ...
 @override
 public void accept(Visitor visitor) {
 visitor.visit(this);
 }
}
```

`방문 대상의 구현 클래스`를 HtmlTag(Element)를 상속받아 만들어준다.
이 역시 인터페이스를 HtmlTag로 통일하기 위함이므로 Composite pattern과 동일하다.

```java:ClassNameVisitor.java
public class ClassNameVisitor implements Visitor {
 @override
 public void visit(HtmlElement element) {
 element.setStartTag(element.getStartTag().replace(">", " class='children'"))
 }

 @override
 public void visit(HtmlParentElement element) {
 element.setStartTag(element.getStartTag().replace(">", " class='parent'"))
 }
} 
```

```java:StyleVisitor.java
public class StyleVisitor implements Visitor {
 @override
 public void visit(HtmlElement element) {
 element.setStartTag(element.getStartTag().replace(">", " style='width: 46px;'"))
 }

 @override
 public void visit(HtmlParentElement element) {
 element.setStartTag(element.getStartTag().replace(">", " style='width: 58px;'"))
 }
} 
```

그리고 `수정을 가할 클래스`를 Visitor를 상속받아 만들어준다.

```java:.java {12-17}
psvm() {
 HtmlTag parentTag = new HtmlParentElement("<div>");
 HtmlTag cTag1 = new HtmlElement("");
 HtmlTag cTag2 = new HtmlElement("");

 parentTag.addChildTag(cTag1);
 parentTag.addChildTag(cTag2);

 Visitor className = new ClassNameVisitor();
 VIsitor style = new StyleVisitor();

 parentTag.accept(className);
 parentTag.accept(style);
 cTag1.accept(className);
 cTag1.accept(style);
 cTag2.accept(className);
 cTag2.accept(style);
}
```

그럼 위와 같은 방식으로 HtmlTag를 수정할 수 있다.

이렇게 하면, Composite들은 accept 메서드만 제공할 뿐, 실제 기능의 추가와 변경은 visitor가 수행하게 된다.
즉, 동적으로 기능을 확장할 수 있고, 기능을 visitor로 분리하여 코드를 관리할 수도 있다.

Visitor 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Visitor Pattern

## 필요성

객체를 만들 때, 상당히 자주 만들어야 하는 객체의 생성방법이 귀찮거나, 오래 걸리는 경우에는 객체를 deep copy 하여 만드는 것이 효율적이다.
java의 경우에는 clone() 메서드를 이용해서 객체를 deep copy할 수 있다.

하나의 객체(Prototype)을 하드코딩하여 생성하고, 이후의 객체는 이 객체를 복사(일부 수정)하는 방식으로 생성하는 패턴을 prototype pattern 이라고 한다.

## Prototype Pattern

```java:Prototype.java
public interface Prototype extends Cloneable {
 public AccessControl clone() throws CloneNotSupportedException;
}
```

java에서는 객체를 clone할 때는 Cloneable marker interface를 상속받는 것이 좋다.
따라서 이 인터페이스를 상속받아 prototype 인터페이스를 만든다.
(AccessControl은 clone 메서드로 생성할 클래스로, 아래에서 구현예정)

<tip>
 clone() 메서드는 최상위 클래스 Object 클래스로부터 상속받을 수 있다.
</tip>

```java:AccessControl.java
public class AccessControl implements Prototype {
 private final String controlLevel;
 private String access;

 public AccessControl(String controlLevel, String access) {
 this.controlLevel = controlLevel;
 this.access = access;
 }

 @override
 public AccessControl clone() {
 try {
 return (AccessControl) super.clone();
 } catch (CloneNotSupportedException e) {
 e.printStackTrace();
 }
 return null;
 }
 // getter...
}
```

그리고 prototype pattern으로 생성할 클래스는 Prototype 인터페이스를 구현하여 만든다.

```java:AccessControlProvider.java {13}
public class AccessControlProvider {
 private static Map<String, AccessControl> new HashMap<String, AccessControl>();
 static {
 map.put("USER", new AccessControl("USER", "DO_WORK"));
 map.put("ADMIN", new AccessControl("ADMIN", "ADD/REMOVE_USER"));
 map.put("MANAGER", new AccessControl("MANAGER", "GENERATE/READ_REPORTS"));
 }

 public static AccessControl getAccessControlObject(String controlLevel) {
 AccessControl ac = null;
 ac = map.get(controlLevel);
 if (ac != null) {
 return ac.clone();
 }
 return null;
 }
}
```

그리고 필요에 따라 객체를 복사하여 사용한다.

<tip>
 왜 ac가 아닌 ac.clone 을 return 하냐면, 그냥 ac를 return할 경우, 모든 객체가 하나의 ac를 포인팅하게 된다.
 즉, shallow copy가 일어나게 된다.
 
 참고롤 객체를 clone 하더라도, 객체의 멤버 변수로 객체를 갖고있다면, 해당 멤버 객체까지 clone되지는 않는다는 점 주의하자.
 (A가 멤버 객체 B를 갖고있을 경우, A' = A.clone()을 한다면, A'는 B'를 포인팅하는 것이 아닌, B를 포인팅하게 된다는 것.)
</tip>

Prototype 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Prototype Pattern


## 필요성

여러 군데에 있는 컴포넌트가 서로 의존성을 갖고있다면, 유지보수하기 어려울 것이다.
그렇다고 해서 도저히 그 의존성을 줄일 방법이 존재하지 않는다면?

Mediator pattern은 모든 컴포넌트가 mediator와 1:1 관계를 갖도록 만들어서 모든 클래스가 종속성있게 복잡하게 구현해야 할 것을 mediator만 의존성을 갖도록 하여 mediator만 복잡하게 구현하도록 하는 방식이다.
(facade pattern과 유사)

## Mediator Pattern

```java:MachineMediator.java
public interface MachineMediator {
  public void start();
  public void wash();
  public void open();
  public void closed();
  public void on();
  public void off();
}
```

우선 여러 컴포넌트가 수행하는 역할의 집약체인 기계가 수행해야 할 기능들을 mediator 인터페이스로 묶어줍니다.

```java:Colleague.java 
public class Colleague {
  public void setMediator(MachineMediator mediator);
}
```

그리고, 여러 컴포넌트가 mediator와 종속성을 갖도록 하기 위해 colleague 인터페이스를 만들어줍니다.

```java:Button.java
public class Button implements Colleague {
  private MachineMediator mediator;

  @override
  public void setMediator(MachineMediator mediator) {
    this.mediator = mediator;
  }

  public void press() {
    mediator.start();
  }
}
```

```java:Machine.java
public class Machine implements Colleague {
  private MachineMediator mediator; 

  @Override
  public void setMediator(MachineMediator mediator) {
    this.mediator = mediator;   
  }

  public void start() { 
    mediator.open();
  }
  public void wash() { 
    mediator.wash();
  }
}
```

그리고 각 컴포넌트에서 각각 기계가 수행해야 할 기능을 mediator 인터페이스와 연결해줍니다.

```java:CottonMediator.java
public class CottonMediator implements MachineMediator {
  private final Machine machine;
  private final Heater heater;
  ...
  public CottonMediator(Machine machine, Heater heater, ...) {
    this.machine = machine;
    this.heater = heater;
    ...
  }

  @override
  public void start() {
    machine.start();
  }

  @override
  public void wach() {
    motor.startMotor();
    motor.rotateDrum(700);
    soilRemoval.low();
  }
  // override other methods
}
```

그리고 마지막으로 하나의 기계에 모든 컴포넌트를 의존성 주입시키면 된다.

그렇다면 코드 실행 부분에서 모든 컴포넌트에 대해 `setMediator()`로 mediator를 등록시켜주고,
위 예시의 경우에는 `button.press()` 만 실행시키면 관련된 모든 코드가 연쇄적으로 실행된다.

CottonMediator 만 본다면 facade pattern과 똑같다.
mediator pattern이 facade와 다른점은 컴포넌트가 setMediator 메서드를 제공하는 하나의 인터페이스로 묶여있다는 점이다.

facade는 facade에서만 컴포넌트를 호출할 수 있었다면,
mediator는 mediator, 컴포넌트에서 서로를 호출할 수 있다.

Mediator 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Mediator Pattern


## 필요성

에러를 핸들링하는 로직을 구현해야 하는 경우, 연쇄적인 try-catch문을 쓰면 코드가 길어질 뿐더러 유지 보수도 어려워진다.
에러 뿐만 아니라 특정 요청만을 처리해야 하는 핸들러를 달아줄 때, if-else를 사용하면 위와 동일한 문제가 생길 뿐더러, 런타임에서 처리 순서를 변경할 수도 없어진다.

위의 모든 문제를 해결하는 방법이 Chain of Responsibility Pattern 이다.

## Chain of Responsibility

파일의 포멧과 상관없는 파일을 읽는 로직을 개발해보자.

```java:File.java
public class File {
  private final String fileName;
  private final String fileType;
  private final String filePath;

  public File(String fileName, String fileType, String filePath) {
    this.fileName = fileName;
    this.fileType = fileType;
    this.filePath = filePath;
  }
  // getter...
}
```

우선 모든 파일을 하나의 인터페이스로 다루기 위해 File 상위 클래스를 만든다.

```java:Handler.java
public interface Handler {
  public void setHandler(Handler handler);
  public void process(File file);
  public String getHandlerName();
}
```

그리고, 핸들링을 연쇄적으로 하기 위해 하나의 인터페이스로 묶어줘야 한다.
따라서 핸들러 인터페이스를 만들어준다.

```java:TextFileHandler.java {16-19}
public class TextFileHandler implements Handler {
  private Handler handler;
  private String handlerName;

  public TextFileHandler(String handlerName) {
    this.handlerName = handlerName;
  }

  @override
  public void setHandler(Handler handler) {
    this.handler = handler;
  }

  @override
  public void process(File file) {
    if (file.getFileName().equals("text")) {
      // process
    } else if (handler != null) {
      handler .process(file);
    } else {
      throw Exception("Not supported file format");
    }
  }
}
```

그리고 인터페이스 규격에 맞게 각 파일 포멧에 해당하는 핸들러를 구현한다.
만약, 포멧이 맞다면, 이 핸들러에서 파일이 처리될 것이고,
포멧이 맞지 않다면, setHandler로 등록된 다음 핸들러에게 파일의 처리를 인가할 것이다.

```java:ReadFile.java {10-12}
public class ReadFile {
  public static void main(String[] args) {
    File file = new File("asd.mp4", "mp4", "~");

    Handler textHandler = new TextHandler("Text Handler");
    Handler excelHandler = new ExcelHandler("Excel Handler");
    Handler audioHandler = new AudioHandler("Audio Handler");
    Handler videoHandler = new VideoHandler("Video Handler");

    textHandler.setHandler(excelHandler);
    excelHandler.setHandler(audioHandler);
    audioHandler.setHandler(videoHandler);

    textHandler.process(file);
  }
}
```

필요에 따라 런타임에 처리 순서를 바꿔줄 수도 있다.

Chain of Responsibility 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Chain of Responsibility


## 필요성

인스턴스를 생성함에 있어, 주입해야할 인자의 개수가 너무 많을 경우 그 순서를 외우는 것은 쉽지 않다.
또한, 클래스가 has-a관계로 depth가 깊은 경우에도 이를 인스턴스로 초기화 하는과정은 매우 복잡할 것이다.

예를 들어 회원정보를 받는 클래스를 만들어보자.

```java:Form.java
public class Form {
  private String firstName;
  private String lastName;
  private String userName;
  private String email;
  private String password;
  private String address;
  private Date dayOfBirth;
  // etc...

  public Form(String firstName, String lastName, ...) {
    //...
  }
}
```

하지만, 위에처럼 인스턴스의 생성을 복잡하게 하지 않도록 하는 방법이 있다.
인스턴스의 생성(초기화)를 유연하고, 보기 편하게 하기 위해 Builder Pattern을 사용한다.

## Builder Pattern

```diff-java:Form.java {18, 28-36, 40-42}
  public class Form {
    private String firstName;
    private String lastName;
    private String userName;
    private String email;
    private String password;
    private String address;
    private Date dayOfBirth;
    // etc...

+   private Form(FormBuilder builder) {
-   public Form(String firstName, String lastName, ...) {
      this.firstName = builder.firstName;
      this.lastName = builder.lastName;
      //...
    }

    public static class FormBuilder {
      private String firstName;
      private String lastName;
      // etc...

      public FormBuilder(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
      }

      public FormBuilder userName(String userName) {
        this.userName = userName;
        return this;
      }

      public FormBuilder email(String email) {
        this.email = email;
        return this;
      }

      // etc...

      public Form build() {
        return new Form(this);
      }
    }
  }
```

builder 클래스를 외부에도 만들 수 있지만, 여기선 이렇게도 할 수 있다는 것을 보여주기 위해 클래스 내부에 넣었다.

특이한 점은 Form 클래스의 생성자가 private 라는 점이다.
즉, 일반적인 방법으로 Form 클래스를 인스턴스화 할 수 없다.
반드시 FormBuilder 클래스를 이용해서 인스턴스화 해야한다.

```java:LoginForm.java
public class LoginForm {
  public static void main(String[] args) {
    FormBuilder builder = new Form.FormBuilder("Woong", "dev");
    builder = builder.email("wjlee611@gmail.com").password("asdasd").userName("dev.Woong");
    Form myForm = builder.build();
  }
}
```

FormBuilder의 생성자에 인자를 집어넣으면 필수로 기입해야 하는 항목을 지정할 수 있고,
email, password, userName과 같은 요소는 순서와 시점에 상관없이 입력을 받을 수 있다.
또한, 인스턴스는 반드시 FormBuilder의 build 메서드를 이용해서만 만들 수 있다.

Builder pattern을 사용하면 마치 클래스의 Iterator를 만들듯이 Builder를 만들어서 생성과정을 은닉할 수 있다.

Builder 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Builder Pattern


## 필요성

자동차를 만든다고 가정해보자.
자동차에는 셀 수 없는 여러 부품들이 종합적으로 들어가서 만들어질텐데, 만약 그 부품이 모두 종속적으로 연결되어 있다면?
부품 교체는 물론이고, 개발하는 것도 여러 사람이 분산해서 개발하지 못할 것이다.

각 부분을 독립적으로 개발하고, 확장을 유연하게 하기 위해 Bridge pattern을 사용한다.

## Bridge Pattern

```java:Product.java
public interface Product {
  public String productName();
  public void produce();
}
```

유연한 확장을 위해 인터페이스를 정의한다.
자동차의 부품에 해당하는 부분이다.

```java:CentralLocking.java
public class CentralLocking implements Product {
  private final String productName;

  public CentralLocking(String productName) {
    this.productName = productName;
  }
  // override methods
}
```
```java:GearLocking.java
public class GearLocking implements Product {
  private final String productName;

  public GearLocking(String productName) {
    this.productName = productName;
  }
  // override methods
}
```

그리고, 여러 사람이 인터페이스에 맞게 부품을 개발한다.

```java:Car.java {2}
public abstract class Car {
  private final Product product;
  private final String carType;

  public Car(Product product, String carType) {
    this.product = product;
    this.carType = carType;
  }

  public abstract void assemble();
  public abstract void produceProduct();
}
```

그리고 자동차의 뼈대를 만들어준다.

이 때, product를 인터페이스로 만들었기에 유연한 확장과, Car과 독립적으로 product를 개발할 수 있게되는데, 이것이 Bridge pattern 이다.

```java:Motoren.java {8}
public class Motoren extends Car {
  public Motoren(Product product, Strint carType) {
    super(product, carType);
  }

  @override
  public void produceProduct() {
    product .produce();
    // ...
  }
}
```

그럼 자동차를 조립하는 입장에서는 produce의 내부 구조는 알 필요없이 인터페이스만을 가지고 독립적으로 개발할 수 있게 된다.

Bridge 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Bridge Pattern

## 필요성

이번엔 피자가게로 예시를 들어보자.
피자 가게에서 피자의 주문을 처리하기 위해서는 아래와 같은 형식으로 코드를 작성해야 할 것이다.

```java:PizzaStore.java
public class PizzaStore {
 ...
 Pizza orderPizza(String tpye) {
 Pizza pizza;

 if (type.equals("cheese")) {
 pizza = new CheesePizza();
 } else if (type.equals("greek")) {
 pizza = new GreekPizza();
 }

 pizza.prepare();
 pizza.bake();
 pizza.cut();
 pizza.box();
 return pizza;
 }
}
```

느낌만 보면 피자의 종류가 추가되거나 변경될 경우 orderPizza 메서드의 수정이 이루어져야 한다.
예시가 적절하지 않은 느낌이 없지않아 있지만, orderPizza의 직접적인 수정이 부담스러울 수 있다.
그 이유는 객체의 생성과 반복되는 메서드 호출 부분이 같은 함수 내에 위치하고 있기 때문이다.

따라서 피자의 생성부(constructor)를 별도의 factory로 관리하는 기법에 대해 알아보자.

## Factory Pattern

이제 객체의 생성부를 factory로 캡슐화를 해보자.

```java:PizzaFactory.java
public class PizzaFactory {
 public Pizza createPizza(String type) {
 Pizza pizza;

 if (type.equals("cheese")) {
 pizza = new CheesePizza();
 } else if (type.equals("greek")) {
 pizza = new GreekPizza();
 }

 return pizza;
 }
}
```

이제 이를 위의 피자가게에 적용한다면 코드는 다음과 같이 수정된다.

```diff-java:PizzaStore.java
 public class PizzaStore {
+ PizzaFactory factory;

 public PizzaStore(Pizzafactory factory) {
+ this.factory = factory;
 }

 public Pizza orderPizza(String type) {
 Pizza pizza;

+ pizza = factory.createPizza(type);
- if (type.equals("cheese")) {
- pizza = new CheesePizza();
- } else if (type.equals("greek")) {
- pizza = new GreekPizza();
- }

 pizza.prepare();
 pizza.bake();
 pizza.cut();
 pizza.box();
 return pizza;
 }
 }
```

이제 코드가 객체의 생성부와 반복되는 메서드의 호출 부분이 분리가 되었다.
따라서 피자의 종류를 추가하거나 변경할 때에는 PizzaStore의 코드를 수정해야할 필요가 없어졌다.

이렇게 하면 또 장점이 PizzaFactory를 교체하는 것 만으로도 생성할 수 있는 객체의 종류를 런타임에 다르게 결정할 수도 있다.

factory 패턴을 이렇게 외부 클래스로 구현할 수도 있지만, 내부의 메서드 형식으로도 구현할 수 있다.
아래 코드를 살펴보자.

```java:PizzaStore.java {11}
public abstract class PizzaStore {
 public Pizza orderPizza(String type) {
 Pizza pizza;

 pizza = createPizza(type);

 ...
 return pizza;
 }

 abstract Pizza createPizza(String type);
}
```

위에서는 PizzaFactory를 교체하는 방식으로 생성하는 객체를 다르게 할 수 있었다.
이제는 이 abstract class를 구현하는 방식으로 생성하는 객체를 다르게 할 수 있다.

```java:NYPizzaStore.java
public class NYPizzaStore extends PizzaStore {
 Pizza createPizza(String type) {
 if (type.equals("cheese")) {
 return new NYStyleCheesePizza();
 } else if (type.equals("greek")) {
 new NYStyleGreekPizza();
 }
 return null;
 }
}
```

참고로 모든 blahPizza는 Pizza 클래스를 상속받는 식으로 구현해야 하고, Pizza 클래스는 abstract로 만들어서 인스턴스로 만들 수 없게 해야한다.

![231125-111929](/posts/final_04/231125-111929.png)

정리하자면, Factory pattern은 객체를 생성하는 인터페이스(createPizza)를 정의할 때
어떤 클래스(blahPizza)를 만들어야 하는지는 상위 클래스(PizzaStore)가 결정하는 것이 아닌,
하위 클래스(NYPizzaStore)에게 일임하는 방식의 디자인 패턴을 의미한다.

<tip>
 참고로 위의 코드는 종속 역전 원칙을 준수한 코드인데, 이게 뭐냐하면
 가능하면 추상 클래스에 대해 종속성을 갖고, 구현 클래스에 대해서는 종속성을 피해야 한다는 디자인 원칙이다.
 
 즉, PizzaStore에서는 객체를 CheesePizza, GreekPizza 로 관리하는 것이 아닌, 오직 Pizza 인터페이스로만 관리하는 것이 좋다.
</tip>

---

## Abstract Factory Pattern

그렇다면 NYPizza와 ChicagoPizza 모두 같은 종류의 피자를 판매한다면?
사실살 들어가는 재료가 다를 뿐, 모두 CheesePizza, PepperoniPizza 등 같은 종류의 파지를 판매할 뿐인데,
각각 다른 종류의 피자 클래스로 구현해야 한다는 문제점이 생길 것이다.

생각해보면, 각 피자는 제조 방식은 같지만, 들어가는 재료가 다를 뿐이다.
따라서 재료의 생성도 factory pattern으로 만든다면?

```java:PizzaIngredientFactory.java
public interface PizzaIngredientFactory {
 public Dough createDough();
 public Sauce createSauce();
 public Cheese createCheese();
 public Veggies[] createVeggies();
 public Pepperoni createPepperoni();
 public Clame createClame();
}
```

우선 각 지역의 피자에 들어갈 재료를 factory pattern으로 만들기에 앞서,
하나의 인터페이스로 묶어주기 위해 인터페이스 클래스를 만들어준다.

```java:NYPizzaIngredientFactory.java
public class NYPizzaIngredientFactory implements PizzaIngredientFactory {
 public Dough createDough() {
 return new ThinCrustDough();
 }

 public Sauce createSauce() {
 return new MarinaraSauce();
 }
 ...
}
```

이후에 각 지역에 맞는 재료 클래스를 반환하는 클래스를 구현해준다.
따라서 각 지역에 피자 매장에 그 지역에 맞는 재료 factory를 종속시켜 준다면,
같은 종류의 피자를 만든다고 할지라도, 재료가 다르게 들어가기 떄문에 지역 특색에 맞는 피자가 만들어 질 것이다.

```java:Pizza.java
public abstract class Pizza { 
 String name;
 Dough dough;
 Sauce sauce;
 Veggies veggies[]; 
 Cheese cheese; 
 Pepperoni pepperoni; 
 Clams clam;

 abstract void prepare(); 

 void bake() {
 System.out.println(“Bake for 25 minutes at 350”); 
 }
 ...
}
```

```java:CheesePizza.java
public class CheesePizza extends Pizza { 
 PizzaIngredientFactory ingredientFactory;

 public CheesePizza(PizzaIngredientFactory ingredientFactory) { 
 this.ingredientFactory = ingredientFactory;
 }

 void prepare() {
 System.out.println(“Preparing “ + name); 
 dough = ingredientFactory.createDough(); 
 sauce = ingredientFactory.createSauce(); 
 cheese = ingredientFactory.createCheese(); 
 }
}
```

그렇기에 피자를 만들 때는 각 재료를 factory로 부터 가져오도록 구현해야 한다.

```java:NYPizzaStore.java
public class NYPizzaStore extends PizzaStore { 
 ...
 protected Pizza createPizza(String item) {
 Pizza pizza = null;

 PizzaIngredientFactory ingredientFactory = 
 new NYPizzaIngredientFactory();

 if (item.equals(“cheese”)) {
 pizza = new CheesePizza(ingredientFactory); 
 pizza.setName(“New York Style Cheese Pizza”);
 } else if (item.equals(“veggie”)) {
 pizza = new VeggiePizza(ingredientFactory); 
 pizza.setName(“New York Style Veggie Pizza”);
 } else if (item.equals(“clam”)) {
 pizza = new ClamPizza(ingredientFactory); 
 pizza.setName(“New York Style Clam Pizza”);
 } else if (item.equals(“pepperoni”)) {
 pizza = new PepperoniPizza(ingredientFactory); 
 pizza.setName(“New York Style Pepperoni Pizza”);
 } 

 return pizza; 
 }
}
```

마지막으로 각 지역에 피자 매장에 그 지역에 맞는 재료 factory를 종속시켜 주면,
같은 종류의 피자를 만든다고 할지라도, 재료가 다르게 들어가기 떄문에 지역 특색에 맞는 피자가 만들어 질 것이다.

![231125-111610](/posts/final_04/231125-111610.png)

이렇게 구현 클래스(PizzaFactory)를 반환하는 것이 아닌, 클래스 생성 후 인터페이스(NYPizzaIngredientFactory)를 반환하는 디자인 패턴을 Abstract Factory Pattern 라고 한다.
간단하게 말하면 factory(NYPizzaStore)의 factory(NYPizzaIngredientFactory) 인 것이다.

Factory 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Factory Pattern

<tip>
 `Proxy`
 다른 기능, 서버를 사용하기 전에 본인선에서 처리해버릴 때, 그 본인을 proxy 라고 한다.
 즉, 중계기로서 대리로 처리하는 것을 의미한다.
</tip>

## Remote Proxy Pattern

![231106-155200](/posts/final_02/231106-155200.png)

프로그램이 서로 다른 머신 혹은 프로세스에서 동작 중일 때, 한 프로그램에서 다른 프로그램의 메서드를 직접 사용하기 위해 서로 상대 프로그램의 proxy를 두어 통신한다.
이렇게 구성하면 각 프로그램은 다른 프로그램의 메서드를 직접 호출한다고 착각하게 되는데, 실제로 통신은 프록시 사이에서 일어나게 되는 것이다.

### 필요성

저번에 만들었던 GumballMachine의 상태를 원격으로 확인하는 서비스를 만들어보자.
api 통신하는 방법으로도 구현할 수 있겠지만, 이번엔 Java에서 지원하는 Remote 기능을 이용해서 구현해보자.

<tip>
 `Java RMI`
 Java Remote Method Invocation은 분산되어 존재하는 객체 간의 메세지 전송을 가능케 하는 프로토콜로, CORBA의 Java 버전이라고 봐도 무방하다.
 
 CORBA는 여러 언어로 구현된 분산 객체간 통신을 가능케 하기 위한 표준으로 이 기술도 함께 알아보면 좋을 듯 하다.
</tip>

### Remote

Remote는 Java에서 제공하는 인터페이스로 내부에 어떠한 메서드도 없다.
즉, Marker interface로서 JVM에게 이 클래스는 RMI 기능을 내포하고 있음을 알려주는 역할로 사용하게 된다.

```java:GumballMachineRemote.java
public interface GumballMachineRemote extends Remote {
 public int getConut() throws RemoteException;
 public String getLocation() throws RemoteException;
 public State getState() throws RemoteException;
}
```

여기서 눈여겨 봐야 할 점은 Remote 메서드들이 모두 RemoteException 에러를 던질 수 있도록 해야한다는 점이다.
그 이유는, 네트워크가 끊기는 경우 프로그램이 정상동작 하지 않을 수 있기 때문이다.

### Examples

그에 따라 상태 클래스도 약간의 변경이 필요하다.

```diff-java:State.java
- public interface State {
+ public interface State extends Serializable {
 public void insertQuarter();
 public void ejectQuarter();
 public void turnCrank();
 public void dispense();
}
```

Serializable 하는 이유는, 네트워크 통신을 할 때 객체를 직렬화해서 전송해야 하기 때문이다.

```diff-java:GumballMachine.java

- public class GumballMachine {
+ public class GumballMachine extends UnicastRemoteObject implements GumballMachineRemote {
 ...

- public GumballMachine(int gums) {
+ public GumballMachine(int gums, String location) throws RemoteException
 ...
 }

 public int getConut() {
 return count;
 }
 public String getLocation() {
 return location;
 }
 public State getState() {
 return state;
 }

 ...
 }
```

여기까지 코드를 수정하고 나면, 이제 원격에서 머신을 실행시키며 RMI 레지스트리에 등록을 해줘야 한다.
따라서 우선 RMI 레지스트리를 활성화 시켜준다.

```bash:shall
$ rmiregistry
```

그다음 원격 머신을 실행시켜준다.

```java:RemoteMain.java
public class RemoteMain {
 public static void main(String args[]) {
 GumballMachineRemote gumballMachine = new GumballMachine(10, "my-location");
 Naming.rebind("//my-location/gumballMachine", gumballMachine);
 }
}
```

여기서 rebind 메서드를 통해 레지스트리에 stub을 등록시켜 주는 것이다.
하지만, stub을 생성 시켜주기위해 아래의 rmic (RMI Compliler) 명령어를 실행하여 만들고 난 뒤 해당 코드를 실행해야 한다.

```bash:shall
$ rmic RemoteMain
$ java RemoteMain
```

이렇게 하면 원격 저장소에 GumballMachineRemote의 stub가 레지스트리에 등록이 되었다!
이제 클라이언트(모니터)에서 데이터를 받아보자.

```java:GumballMonitor.java
public class GumballMonitor {
 GumballMachineRemote machine;

 public GumballMonitor(GumballMachineRemote machine) {
 this.machine = machine;
 }

 public void report() {
 machine.getLocation();
 machine.getConut();
 machine.getState();
 ...
 }
}
```

```java:MonitorMain.java
public class MonitorMain {
 public static void main(String args[]) {
 GumballMachineRemote machine = Naming.lookup("rmi://my-location/gumballMachine");
 GumballMonitor monitor = new GumballMonitor(machine);
 monitor.report();
 }
}
```

여기서 lookup 메서드를 통해 원격 레지스트리에 등록된 stub을 다운로드 받아 사용하는 것이다.

위 과정을 그림으로 표현하면 다음과 같으니 참고하자.

![231119-214628](/posts/final_03/231119-214628.png)

Proxy 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Proxy Pattern


## 필요성

우리가 Gumball machine을 개발한다고 가정해보자.
Gumball machine은 다음과 같은 동작을 수행해야 할 것이다.

![231106-144938](/posts/final_02/231106-144938.png)

개발 경험이 많이 없다면, 해당 동작을 함수 기반으로 작성할 것이다.

```java:GumballMachine.java {9, 12-14}
public class GumballMachine {
  final static int SOLD_OUT = 0;
  final static int NO_QUARTER = 1;
  final static int HAS_QUARTER = 2;
  final static int SOLD = 3;

  private int state = SOLD_OUT;

  public void insertQuarter() {
    if (state == SOLD_OUT) {
      // 껌이 비었기에 동전을 넣게 못하도록 처리
    } else if (state == NO_QUARTER) {
      // 동전을 받았기에 state를 변경
      state = HAS_QUARTER;
    } else if
    ...
  }
}
```

이런식으로 작성한다면 미래의 발견할 문제점이 많다는 것은 둘째치고, 그냥 뭔가 딱 보기에도 불-편하지 않은가?
실제로 다음과 같은 문제점도 발생할 가능성이 높다.

- 상태가 많을수록 조건문이 많아짐
- 상태 상수를 변경하거나, 추가, 삭제시 모든 함수에 대한 수정이 필요함

한 마디로, `유지보수`하기에 너무나도 좋지 못한 방법이다.

## State Pattern

앞의 방식은 상태의 변화, **Transition을 중심**으로 한 코드 작성 방식이었다.

하지만, 상태별로 취해야 할 행동을 다르게 정의하고, 그렇게 정의된 상태를 갖도록 하는 디자인 패턴을 `State Pattern` 라고 하는데,
말로 하면 이해가 어려우니 이번엔 상태, **State를 중심**으로한 코드 작성 방식을 살펴보자.

```java:State.java
public interface State {
  public void insertQuarter();
  public void ejectQuarter();
  public void turnCrank();
  public void dispense();
}
```

우선 각 상태에서 수행해야 할 함수를 모아 State 인터페이스를 만들어주고, 각 상태는 State 인터페이스를 구현하는 방식으로 구현한다.

```java:NoQuarterState.java {8-11}
public class NoQuarterState implements State {
  GumballMachine machine;

  public NoQuarterState(GumballMachine machine) {
    this.machine = machine;
  }

  public void insertQuarter() {
    // 동전을 받았기에 state를 변경
    machine.setState(machine.getHasQuarterState());
  }
  ...
}
```

이런식으로 상태에 따라 수행 가능한 기능을 구현하는 것이다.

```diff-java:GumballMachine.java
  public class GumballMachine {
-   final static int SOLD_OUT = 0;
-   final static int NO_QUARTER = 1;
-   final static int HAS_QUARTER = 2;
-   final static int SOLD = 3;
    // getter 구현
+   State soldOutState;
+   State noQuarterState;
+   State hasQuarterState;
+   State soldState;

-   private int state = SOLD_OUT;
+   private State state = soldOutState;
    int count = 0;

    public GumballMachine(int gums) {
      this.count = gums;
      soldOutState = new SoldOutState(this);
      noQuarterState = new NoQuarterState(this);
      ...
      if (gums > 0) {
        state = noQuarterState;
      }
    }

    public void setState(State state) {
      this.state = state;
    }

    public void insertQuarter() {
-     if (state == SOLD_OUT) {
-       // 껌이 비었기에 동전을 넣게 못하도록 처리
-     } else if (state == NO_QUARTER) {
-       // 동전을 받았기에 state를 변경
-       state = HAS_QUARTER;
-     } else if
-     ...
+     state.insertQuarter();
    }
  }
```

이제 GumballMachine은 상태를 상수로 관리하는 것이 아닌, 클래스로 관리하게 되고, 현재 상태에 따라 호출되는 함수의 기능이 달라지게 된다.

이렇게 구현하면 유지보수도 간편해지는게, 상태를 변경한다고 하면, 해당 상태의 클래스만 수정하면 되고,
상태를 추가한다고 하면 상태 클래스를 추가하고 GumballMachine의 상단에 상태를 보관할 수 있게만 추가하면 된다.

State 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

State Pattern

## 필요성

트리구조와 같은 데이터에 순차 접근해야 하는 상황을 가정해보자.
Iterator pattern으로 구현된 자료구조에 접근할 때의 문제점은, Iterator로 반환되는 객체의 타입이 동일해야 한다는 것이다.
무슨 말이냐면, i번째 접근하는 자료형과 k번째 접근하는 자료형(인터페이스)이 동일해야 한다는 것이다.

이 때 만약, leaf node와 inner node가 다른 방식으로 동작한다고 해서 다른 자료형으로 구현한다면?
노드 타입을 검사하고, 타입에 맞는 순차탐색 과정을 거치는 등 순차탐색하는 과정이 매우 복잡해질 것이다.

## Composite Pattern

이런 순차탐색에서의 불편함을 없애고자, leaf, inner node **모두 동일한 `component class`를 구현**하는 방식을 Composite Pattern 이라고 한다.
예시 코드를 살펴보자.

```java:MenuComponent.java
public abstract class MenuComponent {
 // For inner node
 public void add(MenuComponent c) {
 throw new UnsupportedOperationException();
 }
 public void remove(MenuComponent c) {
 throw new UnsupportedOperationException();
 }
 public MenuComponent getChild(int i) {
 throw new UnsupportedOperationException();
 }
 // For all node
 public void print() {
 throw new UnsupportedOperationException();
 }
 public String getName() {
 throw new UnsupportedOperationException();
 }
 ...
}
```

이제 leaf, inner node에서 위 클래스를 extends 하여 구현하면 모두 동일한 인터페이스(메서드)를 갖게되어 Iterator를 이용한 순차탐색이 가능해진다.
(Iterator\<MenuComponent\> 이런 느낌)

```java:MenuItem.java
// leaf node
public class MenuItem extends MenuComponent {
 String name;
 ...
 public MenuItem(String name, ...) {
 this.name = name;
 ...
 }

 public String getName() {
 return name;
 }

 public void print() {
 System.out.println(getName());
 }
 ...
}
```

이런식으로 필요한 메서드만 override 해서 사용하면 된다.
만약, override하지 않은 메서드를 호출한다면 UnsupportedOperationException이 발생하는 것이다.

```java:Menu.java
public class Menu extends MenuComponent {
 ArrayList menuComponents = new ArrayList();
 String name;
 ...
 public Menu(String name, ...) {
 this.name = name;
 ...
 }

 public void add(MenuComponent c) {
 menuComponents.add(c);
 }
 public void remove(MenuComponent c) {
 menuComponents.remove(c);
 }
 public void getChild(int i) {
 return (MenuComponent)menuComponents.get(i);
 }

 public String getName() {
 return name;
 }

 public void print() {
 System.out.println(getName());
 System.out.println("===========");

 Iterator iter = menuComponents.iterator();
 while(iter.hasNext()) {
 MenuComponent menuComp = (MenuComponent)iter.next();
 menuComp.print();
 }
 }
 ...
}
```

이런식으로 MenuItem(leaf), Menu(inner) 모두 동일한 print 라는 메서드를 호출할 수 있지만,
구현을 다르게 했기 때문에 동작이 달라진다.

이제 메뉴를 출력하든, 메뉴의 각 음식을 출력하든, 나아가 모든 메뉴를 출력(`클라이언트`가 하는 일)하든 상관없이
MenuComponent 클래스를 상속하여 만든 객체는 print를 호출하여 출력할 수 있다.

### vs. Decorator

Menu 클래스를 보면 뭔가 느낌이 Decorator Pattern을 보는 것과 비슷한 느낌을 받을 수 있다.
자식 클래스에서 부모 클래스를 멤버 변수로 가지며, override 한다는 점에서 비슷하다.

하지만, 사용 목적에 차이점이 있음을 알고가면 좋을 거 같다.

`Decorator Pattern`은 leaf node에 해당하는 부분의 **변화를 가하지 않고 추가 기능 구현**을 위해 override 한다는 데 목적이 있다면,

`Composite Pattern`은 계층 구조의 모든 노드가 **같은 인터페이스로 클라이언트에서 접근**할 수 있도록 하는데에 목적이 있다.

Composite 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Composite Pattern

## 필요성

사람마다 개발 스타일이 다르다.
하물며 List, ArrayList 등, 어떤 자료구조가 익숙하냐에 따라 사용하는 데이터 타입 역시 다르다.

만약 분업을 하는데 있어 사람 A는 List, B는 ArrayList를 사용했다고 해보자.
이렇게 자료구조가 다를 경우, 순차탐색에 있어 코드의 구현이 달라진다.

```java:.java
// List
for (int i=0; i<myList.length; i++) {
 myList[i];
}

// ArrayList
for (int i=0; i<myArrayList.size(); i++) {
 myArrayList.get(i);
}
```

만약 위의 순차탐색에서 동작하는 기능이 동알하다면?
자료구조가 다르다는 이유로 같은 기능을 수행하는 동작을 중복해서 작성해야 하는 이슈가 생긴다.

더 심각한건, list를 arrayList와 같이 자료구조를 바꾸기라도 하는 날에는 클라이언트가 코드를 수정해야 한다는 치명적인 문제도 있다.

## Iterator Pattern

Data Collection을 순차적 접근이 필요할 때 그 방식을 Iterator와 같이 제공하는 디자인 패턴을 Iterator Pattern이라고 한다.
위의 코드를 이 디자인 패턴을 적용해 개선해보자.

```java:MyListIterator.java {5, 11}
public class MyListIterator implements Iterator {
 Object[] data;
 int position = 0;

 public MyListIterator(Object[] data) {
 this.data = data;
 }

 public Object next() {
 Object obj = data[position];
 position += 1;
 return obj;
 }

 public boolean hasNext() {
 if (position >= data.length || data[position] == null) {
 return false;
 }
 return true;
 }
}
```

```java:MyList.java {5, 11}
public class MyList {
 ...

 public Iterator createIterator() {
 return new MyListIterator(data);
 }
}
```

이런식으로 나만의 클래스나 Iterator를 제공하지 않는 클래스의 경우 Iterator를 생성하기 위한 클래스를 생성하여 이를 createIterator 에서 반환해주면,
순차 탐색은 createIterator에서 반환된 Iterator를 이용해서 하면 인터페이스를 통일할 수 있다.

<tip>
 MyArrayListIterator는 왜 안 만드는지?
 
 기본적으로 Java에서 `Collection`을 implement 하는 자료구조는 Iterator를 제공하기 때문.
 따라서 얘는 Iterator 클래스를 별도로 구현하지 않아도, 바로 createIterator 메서드 내부에서 `myArrayList.iterator()` 와 같은 방식으로 Iterator를 생성할 수 있음.
 
 예로 들어 Hashtable 자료구조는 values() 라는 메서드를 제공하는데, 해당 메서드는 Collection 객체(아마 ArrayList)를 반환한다.
 즉, Hashtable 자료구조는 myHashtable.values().iterator() 형식으로 Iterator를 얻을 수 있음.
</tip>

```java:.java
// List, ArrayList
while (myIterator.hasNext()) {
 Object obj = myIterator.next();
}
```

한 단계 더 나아가 MyList, MyArrayList를 인터페이스로 묶어 createIterator를 강제할 수 있다.
공통 메서드로 createIterator를 만들어 순차 탐색시에는 Iterator를 사용하도록 유도하는 것이다.

### Single Responsibility

그런데 MyListIterator 클래스를 따로 만들지 않고, 그냥 MyList에서 Iterator를 바로 implements 해서 구현하면 안되는 걸까?

그래도 상관없긴 하다.
하지만, 하나의 클래스는 하나의 역할만 수행한다는 디자인 원칙을 준수하는 것이 코드를 깔끔하게 관리할 수 있도록 도와줄 것이다.

하나의 클래스가 데이터도 관리하고, Iterator도 관리하면... 기능이 너무 복잡해지기 때문이다.

Iterator 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Iterator Pattern

## 필요성

아래와 같은 음료 제조법이 있다고 가정해보자.

> Coffee Recipe
> 1. **Boil some water**
> 2. Brew coffee in Boiling water
> 3. **Pour beverage in cup**
> 4. Add sugar and milk
>
> Tea Recipe
> 1. **Boil some water**
> 2. Steep tea in Boiling water
> 3. **Pour beverage in cup**
> 4. Add lemon

1, 3번 과정은 동일하다.
하지만 음료가 다르다고 같은 제조 과정을 중복해서 적으면 시간도 낭비되고, 수정할 때도 둘 다 수정해야 하는 불편함이 있다.

따라서 **동일한 부분은 함수**로 빼버리고, **다른 부분만 abstract**로 처리하는 기법을 사용하면 이런 불편함을 줄일 수 있을 것이다.

## Template Method Pattern

알고리즘의 뼈대를 정의하고, 서로 다른 부분은 subclass에 미루어 처리하는 디자인 패턴을 Template Method Pattern 이라고 한다.

위의 상황을 코드로 구현하며 알아보자.

```java:Beverage.java {9-10}
public class Beverage {
 final void prepareRecipe() {
 boilWater();
 brew();
 pourInCup();
 addCondiments();
 }

 abstract void brew();
 abstract void addCondiments();

 void boilWater() {
 // boil water
 }

 void pourInCup() {
 // pouring in cup
 }
}
```

```java:Cafe.java
public class Coffee extends Beverage {
 public void brew() {
 // Brew coffee in Boiling water
 }

 public void addCondiments() {
 // Add sugar and milk
 }
}

public class Tea extends Beverage {
 public void brew() {
 // Steep tea in Boiling water
 }

 public void addCondiments() {
 // Add lemon
 }
}
```

이런식으로 하면 두 음료 모두 boilWater, pourInCup 과정은 동일한 코드를 사용할 수 있고,
음료에 따라 다른 brew, addCondiments 과정을 갖게 된다.

또한, 두 음료 모두 Beverage 클래스로 다형성을 유지할 수 있고, 음료 제작 과정은 둘 다 prepareRecipe를 호출하여 실행할 수 있다.

<tip>
 이 방식은 **Hollywood 디자인 원칙** 역시 준수하는데, 이게 뭐냐하면,
 **상위 컴포넌트(클래스)만 호출**하고, **하위 컴포넌트는 호출하지 않고 등록**만 하는 원칙이다.
 
 위의 예시에선 Coffee, tea에서 기능을 수행하지 않고, brew, addCondiments만 등록을 했다.
 실제 호출은 Beverage에서 prepareRecipe에서만 수행했다.
</tip>

## IRL

sort에서도 이와 비슷한 기능이 있다.

```java:MergeSort.java {5}
private static void mergeSort(Object src[], Object dest[],
 int low, int high, int off) {
 for (int i=low; i<high; i++) {
 for (int j=i; j>low 
 && ((Comparable)dest[j-i]).compareTo((Comparable)dest[j])>0; j--) {
 swap(dest, j, j-1);
 }
 }
}
```

Comparable의 compareTo 메서드에서 객체의 비교하는 방법을 정의하게 되는데, 객체간 비교를 하고싶을 때 Comparable 인터페이스의 compareTo 메서드를 구현하면,
이에 따라 객체의 비교 방법이 달라져 mergeSort가 객체간 비교를 가능케 하는 것이다.

Template Method 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Template Method Pattern


## 필요성

개발하다 보면, 이전에 개발했던 코드가 있는데, 새로 개발된 코드 사양에 맞게 변경시켜야 하는 상황이 많을 것이다.
마음같아선 새로 짜고 싶지만, dependency가 높은 코드나 배포가 진행된 코드의 경우 수정하는데 부담이 클 수 밖에 없다.
이런 경우에 오래된 코드를 새로운 코드 사양에 맞게 변형시켜줘야 할 필요성이 생기는데, 이 때 `Adapter Pattern`을 사용하게 된다.

## Adapter Pattern

예를 들어보기 위해 우리의 오랜 친구(?) Duck 시뮬레이터를 다시 불러와보자.

```java:Duck.java
public interface Duck {
  public void quack();
  public void fly();
}
```

이제 새로운 동물을 시뮬레이터에 추가해보자. 바로 Turkey!

```java:Turkey.java
public interface Turkey {
  public void gobble();
  public void fly();
}
```

인터페이스를 보면 알겠지만, 울음 소리가 다르다.
따라서 기존에 많은 곳에서 사용되었던 quack() 메서드를 사용하는 곳에선 Turkey 인터페이스를 구현한 클래스의 인스턴스를 사용할 수가 없게된다.
이 경우 **코드의 재사용성**을 높이기 위해 `Adapter`를 구현해서 사용하게 된다!

```java:TurkeyAdapter.java {1 8-10}
public class TurkeyAdapter implements Duck {
  Turkey turkey;

  public TurkeyAdapter(Turkey turkey) {
    this.turkey = turkey;
  }

  public void quack() {
    turkey.gobble();
  }

  public void fly() {
    turkey.fly();
  }
}
```

이렇게 TurkeyAdapter를 만들어주면 이 어댑터의 인스턴스는 Duck 취급을 받기에 quack() 메서드를 사용하는 부분에 이 인스턴스를 넣을 수 있다.
즉, Turkey를 Duck 처럼 사용할 수 있다는 뜻이다!

```java:DuckSimulator.java {6}
public class DuckSimulator {
  public static void main(String[] args) {
    MallardDuck duck = new MallardDuck(); // implement Duck
    WildTurkey turkey = new WildTurkey(); // inplement Turkey

    Duck turkeyAdapter = new TurkeyAdapter(turkey);

    // 둘 다 가능.
    duck.quack();
    turkeyAdapter.quack(); // 내부적으로 turkey.gobble() 호출
  }
}
```

## IRL

실제로 Adapter Pattern이 적용되는 사례를 살펴보자.

java에서 일련의 객체를 나타낼 때 `Iterator`를 많이들 사용하는데, 예전에 Iterator가 없을 때는 `Enumerators`을 사용했다고 한다.
버전업이 되고 Iterator를 사용하는게 권장됐는데, legacy system에서는 아직도 Enumerators를 사용했기에 이를 강제할 수는 없었다.
따라서 이를 위해 EnumerationAdapter를 만들었다고 한다.

```java:Enumerators.java
public interface Enumerators {
  public boolean hasMoreElements();
  public T nextElement();
}
```

```java:Iterator.java
public interface Iterator {
  public boolean hasNext();
  public T next();
  public void remove();
}
```

```java:EnumerationAdapter.java
public class EnumerationAdapter implements Iterator {
  Enumerators enumerators;

  public EnumerationAdapter(Enumerators enumerators) {
    this.enumerators = enumerators;
  }

  public boolean hasNext() {
    return enumerators.hasMoreElements();
  }

  public T next() {
    return enumerators.nextElement();
  }

  public void remove() {
    throw new UnsupportedOperationException();
  }
}
```



Adapter 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Adapter Pattern

## 필요성

개발하다보면, 특정 버튼을 누르면 이벤트가 발생하도록 처리하는 패턴을 구현해야 하는 경우가 생길 것이다.
예로들어 만능 리모컨을 만든다고 가정해보자.

버튼 1 - ON을 누르면 tv가 켜지고 OFF를 누르면 꺼지고,

```java:TV.java
public class TV {
 private boolean isOn;
 private int channel;

 public TV() {
 this.isOn = false;
 this.channel = 1;
 }

 public void on() {
 this.isOn = true
 }

 public void off() {
 this.isOn = false;
 }

 public void changeChannel(int channel) {
 this.channel = channel;
 }
}
```

버튼 2는 전등, 3은 선풍기 등등...

이런 경우에 보통의 경우 `if - else`로 처리하는 경우가 많을 것이다.

```java:Example
if (버튼 1 - ON) {
 tv.on();
} else if (버튼 2 - OFF) {
 tv.off();
}
```

하지만 이런 경우에는 새로운 기능을 추가하거나, 기존에 있는 기능을 수정하려면 그 유지보수가 매우 불편하다.

따라서 이를 해결하기 위한 디자인 패턴을 소개한다.

## Command Pattern

Command Pattern의 기본적인 아이디어는 모든 기능 요청들을 `하나의 명령어(Command)`로서 관리하여 은닉화 하는데에 있다.
바로 코드를 보며 이해해보자.

```java:Command.java
public interface Command {
 public void execute();
}
```

```java:TVOnCommand.java {1, 8-10}
public class TVOnCommand implements Command {
 TV tv;

 public TVOnCommand(TV tv) {
 this.tv = tv;
 }

 public void execute() {
 tv.on();
 }
}
```

모든 명령어는 무조건 `execute()`로 실행하고, 각 명령어의 실행 방법은 그 명령어가 어떤 장치를 조작하는지에 따라 다르게 구현한다.
따라서 이렇게 구현한다면 TV를 켜든 끄든 전등을 제어하든 모든 명령은 `execute()`를 호출하면 되는 것이다.

```java:RemoteController.java {2-3}
public class RemoteController {
 Command[] onCommands;
 Command[] offCommands;

 public RemoteController() {
 onCommands = new Command[7];
 offCommands = new Command[7];

 Command empty = new Command();
 for (int i=0; i<onCommands.length; i++) {
 onCommands[i] = empty;
 offCommands[i] = empty;
 }
 }

 public void setCommand(int slot, Command onCom, Command offCom) {
 onCommands[slot] = onCom;
 offCommands[slot] = offCom;
 }

 public void onBtnPushed(int slot) {
 onCommands[slot].execute();
 }

 public void offBtnPushed(int slot) {
 offCommands[slot].execute();
 }
}
```

그리고 만능 리모컨을 이렇게 구현한다면, 사용자 입장에서는 원하는 기능을 `Command interface`로 구현하고, 원하는 slot에 `setCommand()`를 이용해 넣어주기만 하면 된다.

### 추가 기능

명령어 인터페이스를 이용해 하나로 구현하면 다른 기능을 추가하고 싶을 때도 용이하다.
예로 들어 undo 기능을 구현해보자.

```diff-java:Command.java
 public interface Command {
 public void execute();
+ public void undo();
 }
```

그럼 각 명령어에서 수행할 undo 기능을 추가만 하면 된다.

```diff-java:TVOnCommand.java
 public class TVOnCommand implements Command {
 TV tv;

 public TVOnCommand(TV tv) {
 this.tv = tv;
 }

 public void execute() {
 tv.on();
 }

+ public void undo() {
+ tv.off(); // on의 반대는 off
+ }
 }
```

그렇다면 컨드롤러의 구현은 이렇게만 수정되면 undo 기능을 쉽게 구현할 수 있게된다!

```diff-java:RemoteController.java
 public class RemoteController {
 Command[] onCommands;
 Command[] offCommands;
+ Command undoCommand;

 ...

 public void onBtnPushed(int slot) {
 onCommands[slot].execute();
+ undoCommand = onCommands[slot];
 }

 public void offBtnPushed(int slot) {
 offCommands[slot].execute();
+ undoCommand = offCommands[slot];
 }

+ public void undoBtnPushed() {
+ undoCommand.undo();
+ }
 }
```

undo 뿐만 아니라, 매크로 기능과 같은 서드파티 기능도 쉽게 구현할 수 있을 것이다.

```java:MacroCommand.java
public class MacroCommand implements Command {
 Command[] commands;

 public MacroCommand(Command[] commands) {
 this.commands = commands;
 }

 public void execute() {
 for (int i=0; i<commands.length; i++) {
 commands[i].execute();
 }
 }

 public void undo() {
 for (int i=commands.length-1; i>=0 i--) {
 commands[i].undo();
 }
 }
}
```

### IRL

In Real Life에서는 Command Pattern이 어떻게 쓰이고 있을까?

1. 명령어 queuing
**Command queue**를 만들어 `enqueue`, `dequeue`를 구현하여, 각각의 명령어를 순차처리, 스레드에 할당하는 방식으로 사용하는 경우가 있다.

2. logging
**Command**에 `store`, `load` 따위의 메서드를 추가하여 명령어가 실행되면 disk에 로깅 및 불러올 수 있도록 기능을 추가하여 에러 및 데이터 분석을 용이하게 하는 경우도 있다.


## 결론

클라이언트 별로 다른 요청을 처리하는 경우나, 요청 queue, 로깅이 필요한 경우에는
명령어, 요청을 `은닉화(encapsulates)`하는 Command Pattern을 활용해보자.

Command 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Command Pattern


## 필요성

시스템 전체에서 하나의 클래스가 하나의 인스턴스만 생성해야 하는 경우 사용한다.

## Singleton Pattern

```java:Singleton.java {2, 4} showLineNumbers
  public class Singleton {
    private static Singleton _instance;

    private Singleton() {}

    public static Singleton getInstance() {
      if (_instance == null) {
        _instance = new Singleton();
      }
      return _instance;
    }
  }
```

기존에 봐오던 클래스들과 많이 다르게 클래스 내부에 본인의 인스턴스를 저장하는 공간이 있으며,
**생성자가 외부로 노출되지 않는다**.

인스턴스 생성은 오직 `getInstance()` 메서드 호출을 통해서만 이루어지며,
내부적으로 null값인 경우에만 인스턴스를 생성하기 때문에 `1개의 인스턴스만 생성`이 된다.

### Multithreading

하지만 멀티스레딩 환경에서는 인스턴스가 2개 이상 생성되는 경우가 발생할 수 있다.
`Line 7`과 `Line 8` 사이에서 `Context switching`이 일어나는 경우가 그러하다.

이런 경우를 막기 위해서 getInstance()는 `동기화 처리`를 해주는 편이 좋다.

```java:Singleton.java {2}
public class Singleton {
  private static Singleton _instance = new Singleton();
  ...
}
```

이렇게 하면 프로그램 실행시점에 인스턴스가 생성되어 반드시 1개의 인스턴스만 생성할 수 있다.
하지만, 해당 클래스의 생성시점을 제어할 수 없기에 프로그램 성능이 저하되는 문제가 발생할 수 있다.

```java:Singleton.java {6}
  public class Singleton {
    private static Singleton _instance;

    private Singleton() {}

    public static synchronized Singleton getInstance() {
      if (_instance == null) {
        _instance = new Singleton();
      }
      return _instance;
    }
  }
```

java처럼 동기화 키워드를 제공하는 경우 인스턴스를 생성하는 함수를 동기화 걸어주면 된다.
하지만 이 경우에도 해당 함수가 매우 무거운 기능을 수행하는 경우에는 동기화 시간이 매우 길어져 성능 저하의 원인이 될 수 있다.


```java:Singleton.java {6}
  public class Singleton {
    private volatile static Singleton _instance;

    private Singleton() {}

    public static Singleton getInstance() {
      if (_instance == null) {
        synchronized (Singleton.class) {
          if (_instance == null) {
            _instance = new Singleton();
          }
        }
      }
      return _instance;
    }
  }
```

위의 코드는 인스턴스 생성 함수 내부에서 정확히 인스턴스를 생성하는 부분만 동기화되기 때문에
성능상의 이슈도 없앨 수 있다.

## 결론

필요성과 같다.
시스템 전체에서 하나의 클래스가 하나의 인스턴스만 생성해야 하는 경우 사용하자.

Singleton 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Singleton Pattern


## 필요성

키오스크 개발자라고 가정하고 음료를 정의할 인터페이스를 만들어보자.

```java:Beverage.java
public abstract class Beverage {
  private String description;

  public Beverage(String des) {
    this.description = des;
  }

  public String getDescription() {
      return description;
  }
  public abstract double cost();
}
```

그렇다면 음료들은 이 클래스를 상속받아서 구현하면 될 것이다.
하지만 이 경우에 다음과 같은 문제점이 발생할 수 있다.

아아, 아아 샷추가, 아아 우유추가 등 여러 `베리에이션 음료`에 대해 모두 **각각** 클래스로 구현해야 한다는 점이다.
단순히 샷추가나 우유추가의 경우에는 가격만 좀 더 받으면 될터인데 이를 각각 따로 구현하는거는 코드의 중복 뿐만 아니라, 유지보수도 어렵게 만든다.

### OCP

그렇다면 Beverage에서 옵션도 관리하게 하면 되지 않을까?

```diff-java:Beverage.java
  public abstract class Beverage {
    private String description;
+   private boolean milk;
+   private boolean soy;

    public Beverage(String des) {
      this.description = des;
    }

    public abstract String getDescription() {
      return description;
    }
    public abstract double cost();

+   setMilk();
+   hasMilk();
+   setSoy();
+   hasSoy();
  }
```

처음 생각해볼 수 있는 간단한 해결법이지만, 좋은 방법은 아니다.
다른 옵션을 추가하거나 옵션에 따른 가격 변동을 수정하려는 경우에는 Beverage 클래스에 대한 전면적인 수정이 필요해지기 때문이다.

`새로운 옵션`에 대해서는 **변수 추가 및 get, set을 추가**해야 하고,
`가격 변동`의 경우에는 **cost 함수가 전면적으로 수정**되어야 한다.
이 과정에 Beverage를 상속받은 `모든 클래스`에서 일어나야 한다.

이런 경우를 방지하기 위해 `OCP` 방법론을 준수하여 코딩하는게 좋다.

OCP는 Open-Closed Principle의 약어로, 확장엔 유연하게, 변경엔 엄격하게 디자인 해야함을 추구하는 원칙이다.

## Decorator Pattern

이를 해결하기 위해 `Decorator Pattern`을 사용할 수 있다.

우선 Beverage는 다시 원상복구를 시키고, 옵션에 대한 클래스를 구현하자.

```java:CondimentDecorator.java
public abstract class CondimentDecorator extends Beverage {
  public abstract String getDescription();
}
```

이제 음료는 Beverage를 상속받아 구현하고, 옵션은 CondimentDecorator를 상속받아 구현하면 된다.
계속 예시를 살펴보며 이해하자.

```java:Espresso.java
public class Espresso extends Beverage {
  public Espresso() {
    description = 'Espresso';
  }

  public double cost() {
    return 0.89;
  }
}
```

```java:Milk.java
public class Milk extends CondimentDecorator {
  Beverage beverage;

  public Milk(Beverage beverage) {
    this.beverage = beverage;
  }

  public String getDescription() {
    return beverage.getDescription() + ', Milk';
  }

  public double cost() {
    return beverage.cost() + 0.20;
  }
}
```

이런식으로 구현한다면 사용할 때는 Espresso를 Milk가 감싸는 방식으로 옵션을 추가할 수 있게된다.

```java:Kiosk.java
public class Kiosk {
  public static void main(String args[]) {
    Beverage espressoWithMilk = new Milk(new Espresso());
    System.out.println(espressoWithMilk.getDescription() + “ $” + espressoWithMilk.cost());
    ...
  }
}
```

> Espresso, Milk $1.09

실제로 Java의 I/O를 사용하다보면 이런 코드를 많이 본 적이 있을 것이다.

```java:FileIO.java
InputStream in = new LineNumberInputStream(
                    new BufferedInputStream(
                       new FileInputStream('text.txt')));
```

이런 Stream도 모두 Decorator Pattern이 적용된 것이다.

## 결론

Decorator Pattern은 `새로운 기능이 추가`되거나, `적용 순서를 자유롭게` 해야하는 경우에 사용하는 것이 좋다.

Decorator 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Decorator Pattern

## Strategy Pattern

[**저번 포스트**](https://wjlee611.github.io/blog/univ_design-pattern/mid_01)에서 배운 `Strategy 디자인 패턴`을 이용해서 한 가지 예를 살펴보자.

```java:WeatherData.java {7} showLineNumbers
public class WeatherData {
 public void measurementsChanged() {
 float temp = getTemperature();
 float humidity = getHumidity();
 float pressure = getPressure();

 // 각 장치는 update라는 전략을 사용하는 전략 클래스를 갖고있는 클래스이다.
 currentConditionsDisplay.update(temp, humidity, pressure);
 statisticsDisplay.update(temp, humidity, pressure);
 forecastDisplay.update(temp, humidity, pressure);
 }
}
```

이 코드는 `Display`장치들이 `WeatherData`에서 제공하는 데이터를 이용하려는 코드이다.

예로 들어 `forecastDisplay`에서 날씨 정보를 출력하기 위해서는
`WeatherData`에서 `forecastDisplay.update()` 메서드를 호출해야
날씨 정보가 비로소 `forecastDisplay`로 전달되는 것이다.

### 문제점

여기서 문제가 발생한다.
만약 새로운 장치 futureDisplay를 구현하려면 Strategy Pattern을 사용하는 코드는 아래와 같은 코드수정이 필요해진다.

1. update() 전략을 갖고있는 인터페이스로 구현한 전략(Display) 클래스를 만든다.
2. `Line 7`에 새로운 장치를 등록한다.

지금 당장은 문제될게 없어 보이지만, 만약 당신이 WeatherData를 `라이브러리화 해서 배포`하는 입장일 경우를 고려해보자.
`사용자`는 단지 새로운 Display를 추가하여 바로 날씨 정보를 받아오고 싶을 것이다.
하지만, 위와 같은 코드라면 사용자는 라이브러리 파일을 뜯어서 WeatherData 클래스 내부에
직접적으로 `새로운 Display를 의존성 주입`을 해줘야만 할 것이다.

이 경우는 꽤나 치명적이다.
생각해보면 우리가 사용하는 대부분의 라이브러리는 이런 과정을 겪지 않으니 말이다.

따라서 이런 문제를 해결하기 위한 디자인 패턴이 필요하다.

## Observer Pattern

Observer Pattern의 정의는 다음과 같다.

> 객체들이 1:N의 관계를 갖을 때, 한 객체의 상태가 변하면 다른 모든 객체들에 업데이트 통지가 떨어지는 관계로,
> `객체(Subject)`와 `객체들(Observers)`간의 `종속성이 없는 관계`를 의미한다.

코드로 살펴보며 이해해보자.

### interface

```java:IObserverPattern.java {1-5, 7-9}
public interface Subject {
 public void registerObserver(Observer o);
 public void removeObserver(Observer o);
 public void notifyObservers();
}

public interface Observer {
 public void update(float temp, float humidity, float pressure);
}

public interface DisplayElement {
 public void display();
}
```

위 코드는 Observer Pattern에서 사용하는 인터페이스이다.
`1`의 입장인 클래스(Subject)는 `Subject 인터페이스`를 구현해야 하고,
`N`의 입장인 클래스(Observers)는 `Observer 인터페이스`를 구현해야 한다.

### Subject class

```diff-java:WeatherData.java {24, 35}
 public class WeatherData implements Subject {
+ private ArrayList<Observer> observers;

 public WeatherData() {
 observers = new ArrayList<Observer>();
 }

+ @implements
+ public void registerObserver(Observer o) {
+ observers.add(o);
+ }
+
+ @implements
+ public void removeObserver(Observer o) {
+ int i = observers.indexOf(o);
+ if (i < 0) return;
+ observers.remove(i);
+ }
+
+ @implements
+ public void notifyObservers() {
+ for (int i=0; i<observers.length; i++) {
+ Observer o = observers.get(i);
+ o.update(temp, humidity, pressure);
+ }
+ }

 public void setMeasurements(float temp, float humidity, float pressure) {
 this.temp = temp;
 this.humidity = humidity;
 this.pressure = pressure;
 measurementsChanged();
 }

 // 더이상 WeatherData 클래스는 수정할 일이 없어진다.
 public void measurementsChanged() {
+ notifyObservers()
- float temp = getTemperature();
- float humidity = getHumidity();
- float pressure = getPressure();
-
- // 각 장치는 update라는 전략을 사용하는 전략 클래스를 갖고있는 클래스이다.
- currentConditionsDisplay.update(temp, humidity, pressure);
- statisticsDisplay.update(temp, humidity, pressure);
- forecastDisplay.update(temp, humidity, pressure);
 }
 }
```

Subject class의 역할은 Observer의 `구독과 해지`하는 역할을 담당하고,
구독된 Observers에게 `본인의 변경사항을 알려`주는 역할을 한다.

본인의 변경사항을 알려주기 위해 `Observer는 update 전략`을 포함하고 있어야 한다.

이제 Subject 클래스는 `구독된 Observer를 배열로 관리`하고, `관리되고 있는 Observer를 대상`으로 `변경사항을 emit(update)`하기 때문에
**더이상 Subject 클래스를 수정할 필요가 없어진다.**

### Observer class

```java:FutureDisplay.java {6-8}
public class FutureDisplay implements Observer, DisplayElement {
 private Subject weatherData;

 public FutureDisplay(Subject weatherData) {
 this.weatherData = weatherData;
 // Observer가 Subject를 구독한다.
 // 비로소 Subject가 update를 쏴줄 수 있다.
 weatherData .registerObserver(this);
 }

 public void update(float temp, float humidity, float pressure) {
 this.temp = temp;
 this.humidity = humidity;
 this.pressure = pressure;
 display();
 }

 @implements
 public void display() {
 // ...
 }
}
```

Observer는 생성시 자동으로 `Subject를 구독`하게 되고,
구독했기에 Subject의 상태 변경시 자동으로 Observer를 업데이트 할 수 있다.
_Subject의 observers 배열에 추가되어 관리됨_

> 여기서 눈여겨 봐야 할 점은 `Observer의 update` 전략 메서드는 `Subject`에서,
> `Subject의 register, remove` 전략 메서드는 `Observer`에서 호출된다는 점이다.
> 서로 `크로스`되어 메서드를 호출한다는 점을 주목하자.

### main (사용자 입장)

```diff-java:WeatherStation.java {5-6}
 public class WeatherStation {
 public static void main(String[] args) {
 WeatherData weatherData = new WeatherData();

 // another displays
+ FutureDisplay futureDisplay = new FutureDisplay(weatherData);

 weatherData.setMeasurements(80, 65, 30.4f);
 weatherData.setMeasurements(82, 70, 29.2f);
 weatherData.setMeasurements(78, 90, 29.3f);
 }
 }
```

사용자 입장에서는 새로운 Display객체 생성시 WeatherData를 의존성 주입만 해주면,
그 뒤의 모든 과정은 Observer Pattern에 의해 자동으로 업데이트가 가능해진다.

## 결론

`의존성이 없어`야 하지만 `여러 클래스와 관계`를 가져야하고,
동시에 `코드가 수정되는 일이 적어`야만 하는 클래스는
Observer Pattern을 그 클리스와 관계를 갖는 여러 클래스에 적용하는 것이 좋다.

Observer 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Observer Pattern


## 상속

### extends

오리 시뮬레이터를 만든다고 가정해보자.
그렇다면 일단 오리 객체를 만들어야 할 것이다.

```java:Duck.java {5}
class Duck() {
  quack() {};
  swim() {};
  fly() {};
  display() {};
  // other duck-like methods
}
```

그리고 여러 종류의 오리는 이 `Duck` 클래스를 상속받아서 사용하면 될 것이다.

```java:Ducks.java {2-3, 7-8}
class MallardDuck extends Duck {
  @override
  display() {};
}

class RedheadDuck extends Duck {
  @override
  display() {};
}
```

물론 생김새는 다르기에 일부 메서드는 `override`해서 사용해야 할 것이다.
이 때 자식 클래스와 부모 클래스는 `is a` 관계를 갖는다고 말한다.
_e.g. MallardDuck is a Duck_

### implements (interface)

이제 고무 오리를 만들어보자.

```java:Ducks.java {4-7}
class RubberDuck extends Duck {
  @override
  display() {}
  @override
  quack() {}
  @override
  fly() {}
}
```

고무 오리는 `꽥` 소리를 내지 않고 `삑`소리를 내기 때문에 `quack()` 메서드 역시 override 해야한다.
또한, 날지도 않기에 `fly()` 메서드 역시 override 해야한다.

DecoyDuck을 또 만든다면?
이 역시 quack, fly 메서드를 override 해야한다.

이렇게 모든 Duck들이 공유하지 않는 속성은 매번 override 해야하는 문제점이 있다.

이 때, `interface`를 사용하면 이 문제를 해결할 수 있다.

```diff-java:DucksWithInterfece.java {12, 18}
  class Duck() {
    swim() {};
    display() {};
  }
+ interface Flyable() {
+   fly();
+ }
+ interface Quackable() {
+   quack();
+ }

  class MallardDuck extends Duck implements Flyable, Quackable {
+   fly() {};
+   quack() {};
    @override
    display() {};
  }
  class RubberDuck extends Duck implements Quackable {
+   quack() {};
    @override
    display() {};
  }
```

이렇게 변할 수 있는 부분은 interface로 띄어내면 쓸데없이 메서드를 override할 일이 줄어든다.
이 때 구현 클래스와 인터페이스는 `has a` 관계를 갖는다고 한다.
_e.g. RubberDuck has a Quackable_

_참고:_
_class, interfece의 차이는 사실 거의 없다._

### interface 다형성

하지만 위 방식 역시 문제가 존재한다.
MallardDuck, RedheadDuck 두 오리 모두 같은 quack 메서드로 동작해야 하지만,
이를 implements 하는 과정에서 두 메서드를 중복해서 구현해야 한다는 문제점이 발생한다.

이를 해결하기 위해서는 인터페이스의 다형성의 원리를 이용하는게 좋다.

```diff-java:DucksWithPolymorphism.java {18, 20-24}
  interface QuackBehavior {
    quack();
  }
+ class Quack implements QuackBehavior {
    @override
    quack() {'꽥'};
  }
+ class Squack implements QuackBehavior {
    @override
    quack() {'삑'};
  }
+ class MuteQuack implements QuackBehavior {
    @override
    quack() {};
  }

  class Duck {
    QuackBehavior quackBehavior;

    performQuack() {
      // delegate to the behavior class
      // 한 마디로 짬때리기...
      quackBehavior.quack();
    }
    // ...
  }

  class MallardDuck extends Duck {
    MallardDuck() {
      // 다형성의 원리에 의해 QuackBehavior 타입에 Quack 객체를 지정할 수 있다.
+     quackBehavior = new Quack();
    }

    // 구현 없이 바로 performQuack 메서드(꽥)를 사용할 수 있음.
    // ...
  }
  class RubberDuck extends Duck {
    MallardDuck() {
      // 다형성의 원리에 의해 QuackBehavior 타입에 Squack 객체를 지정할 수 있다.
+     quackBehavior = new Squack();
    }

    // 구현 없이 바로 performQuack 메서드(삑)를 사용할 수 있음.
    // ...
  }
```

이렇게 하면 필요한 부분에만 기능을 추가할 수 있고, 코드의 재사용성도 올라간다.
뿐만 아니라 새로운 기능 (예로 들어 새로운 울음 소리)의 추가도 쉬워진다.

## Strategy Pattern

위에서 알아본 적절한 상속관계를 준수한 패턴을 `Strategy Pattern` 라고 한다.
정확한 정의는 다음과 같다.

> 객체들이 할 수 있는 행위 각각에 대해 `전략 클래스 (Quack, Squack)`를 생성하고,
> `유사한 행위들을 캡슐화` 하는 `인터페이스 (QuackBehavior)`를 정의하여,
> 객체의 행위를 동적으로 바꾸고 싶은 경우 `직접 행위를 수정하지 않고 (performQuack())`
> 전략을 바꿔주기만 함으로써 행위를 유연하게 확장하는 방법을 말합니다.

간단히 말해서 객체가 할 수 있는 행위들을 각각을 전략으로 만들어 놓고, 동적으로 행위의 수정이 필요한 경우 전략을 바꾸는 것만으로 행위의 수정이 가능하도록 만든 패턴이다.

## 결론

`has a (구현)`관계가 `is a (상속)`관계보다 낫다.

상속은 뭘 상속해야 하는지 일일이 파악해야 하는 귀찮음이 있기 때문이다.
하지만, 구현은 필요한 기능만 가져다 쓰면 되기에 사용및 개발적 측면에서 좋고,
새로운 기능은 인터페이스를 추가로 구현하면 끝이기에 유지보수 측면에서도 좋다.

따라서 단순히 상속을 이용한 객체지향 프로그래밍 보단,
전략 패턴을 적용한 코딩 습관을 기르도록 하자.


Strategy 디자인 패턴의 필요성과 그 구조에 대해 알아봅니다.

Strategy Pattern

3학년 2학기 프로그래밍 언어론 수업 아카이브