2월 4주차 디자인 패턴과 프로그래밍 패러다임 - 1.1.3 전략 패턴, 1.1.4 옵저버 패턴

[Mins00oo]

✔전략 패턴

---

🎈개념

• 정책 패턴(policy pattern)이라고도 하며, 객체의 행위를 바꾸고 싶은 경우 ‘직접’ 수정하지 않음

• 컨텍스트 안에서 ‘전략’이라 불리는 ‘컨텍스트 알고리즘’을 바꿔주면서 상호 교체가 가능하게

• 컨텍스트 알고리즘 ?

  전략이라 불리며 전략 패턴에서 별도로 분리가 된다.

• 컨텍스트

  문맥, 맥락을 의미하며 개발자가 어떤 작업을 완료하는데 필요한 모든 관련 정보

)

✨예시

예시 - 1️⃣

public class Calculator {
    public int calculate(boolean firstGuest. List<Item> items) {
        int sum = 0;

        for(Item item : items) {
            if(firstGuest) {
                sum += (int)(item.getPrice() * 0.9); // 첫 손님 10% 할인
            } else if(!item.isFresh()) {
                sum += (int)(item.getPrice() * 0.8); // 덜 신선한 것 20% 할인
            } else {
                sum += item.getPrice();
            }
        }

        return sum;
    }
}

• 한 매장에서 손님을 위한 2가지 할인 정책을 열었다
• 1개는 첫 손님을 위한 10%할인 정책이고, 1개는 덜 신선한 과일에 대한 20% 할인 정책
• 현재 위와 같은 코드에서는 서로 다른 정책들이 if-else문으로 섞여있다보니, 정책이 추가될때마다 코드 수정이 어려워진다.
• 그럼 여기서, 가격 할인 정책을 별도 객체로 분리해보면 ?

• Calculator 클래스는 가격 합산 계산의 책임을 진다. → 콘텍스트(Context)
• DiscountStrategy 인터페이스는 할인금액 계산을 추상화한다. → 전략(Strategy)
• 전략 패턴에서는 Context는 사용할 전략을 직접 선택하지 않고 clinet가 사용할 전략을 DI를 이용해 전달받는다.

public class Calculator {
    private DiscountStrategy discountStrategy;

    public Calculator(DiscountStrategy discountStrategy) {
        this.discountStrategy = discountStrategy;
    }

    public int calculate(List<Item> items) {
        int sum = 0;

        for(Item item : items) {
            sum += discountStrategy.getDiscountPrice(item);
        }

        return sum;
    }
}

public interface DiscountStrategy {
    int getDiscountPrice(Item item);
}

public class FirstGuestDiscountStrategy implements DiscountStrategy {
    @Override
    public int getDiscountPrice(Item item) {
        return (int)(item.getPrice() * 0.9);
    }
}

private DiscountStrategy strategy;

public void onFirstGuestButtonClick() {
    // 첫 손님 할인 버튼 누를 때 생성 됨
    strategy = new FirstGuestDiscountStrategy();
}

public void onCalculationButtonClick() {
    // 계산 버튼 누를 때 실행 됨
    Calculator cal = new Calculator(strategy);
    int price = cal.calculate(items);
    ...
}

• 이점: Context 코드의 변경없이 새로운 전략을 추가할 수 있다.
• Calculator 클래스는 정책 확장엔 열려있고 변경엔 닫혀있는 개방.폐쇄 원칙(OCP)도 따른다.

예시 - 2️⃣

• Clinet가 기차와 버스를 이용한다고 생각하면 된다.

public interface Movable {
    public void move();
}

public class Train implements Movable{
    public void move(){
        System.out.println("선로를 통해 이동");
    }
}

public class Bus implements Movable{
    public void move(){
        System.out.println("도로를 통해 이동");
    }
}

public class Client {
    public static void main(String args[]){
        Movable train = new Train();
        Movable bus = new Bus();

        train.move();
        bus.move();
    }
}

• 만약 여기서 버스 전략이 새롭게 달라졌다면? 선로를 따라 이동하는 버스가 생겼다면?

public void move(){
    System.out.println("선로를 따라 이동");
}

하지만, 위와 같이 코드를 수정하면 SOLID 원칙 중 OCP에 위배된다.

• OCP에 의하면 기존의 move메소드를 수정하지 않으면서 행위가 수정되어야 한다.
• 시스템이 확장이 될 경우 메소드의 중복문제 발생

따라서, 다시 전략 패턴에 따라 수정한다면 ?

• 현재 전략은 움직이는 방식에 따라, 선로를 따라서인지 혹은 도로를 따라서인지 방식이 있다.
• 두 전략 클래스를 만들고 move메소드를 구현하여 어떤 경로로 움직이는지에 대해 구현한다.
• 인터페이스를 통해 캡슐화 하는 이유는 다른 전략들이 추가적으로 확장되는 경우를 고려한 설계

public interface MovableStrategy {
    public void move();
}

public class RailLoadStrategy implements MovableStrategy{
    public void move(){
        System.out.println("선로를 통해 이동");
    }
}

public class LoadStrategy implements MovableStrategy{
    public void move() {
        System.out.println("도로를 통해 이동");
    }
}

다음은 운송 수단에 대한 클래스를 정의

운송 수단은 move() 메소드를 통해 움직일 수 있는데 직접 구현하지는 않고, 어떻게 움직일 것인가에 대한 전략을 설정하여 그 방식으로 움직이도록 한다.

따라서, setMovableStrategy()가 존재한다.

public class Moving {
    private MovableStrategy movableStrategy;

    public void move(){
        movableStrategy.move();
    }

    public void setMovableStrategy(MovableStrategy movableStrategy){
        this.movableStrategy = movableStrategy;
    }
}

public class Bus extends Moving{

}

public class Train extends Moving{

}

마지막으로 운송 수단을 사용하는 Client를 구현할 차례

각 운송수단 객체를 생성한 후, 운송 수단이 어떻게 움직이는지 설정하기 위해 setMovableStrategy를 호출한다.

public class Client {
    public static void main(String args[]){
        Moving train = new Train();
        Moving bus = new Bus();

        /*
            기존의 기차와 버스의 이동 방식
            1) 기차 - 선로
            2) 버스 - 도로
         */
        train.setMovableStrategy(new RailLoadStrategy());
        bus.setMovableStrategy(new LoadStrategy());

        train.move();
        bus.move();

        /*
            선로를 따라 움직이는 버스가 개발
         */
        bus.setMovableStrategy(new RailLoadStrategy());
        bus.move();
    }
}

• 장점

  • if -else 분기를 제거해서 context의 코드 변경 없이 전략을 추가할 수 있다.
  • 확장에 유리한 코드를 작성할 수 있다.
    • OCP 원칙을 준수한 코드 작성이 가능하다.

• 단점

  • 애플리케이션에 들어가는 모든 전략을 다 알고 있어야 한다.
    • 클래스로 분리된 전략들이 어느 상황에 사용되는지 다 알아야 한다.
    • 어찌보면 유지보수가 더 어려울지도..
  • 전략을 추상화한 인터페이스가 효율적이지 못할 수 있다.
    • 어떤 전략 콘크리트 객체에선 사용하지 않는 메소드들 역시 전략 인터페이스에 정의해 주어야 한다.

• 참고 링크

  [[Design Pattern] 스트래티지 패턴이란 - Heee's Development Blog](https://gmlwjd9405.github.io/2018/07/06/strategy-pattern.html)

  [[디자인패턴] 전략 패턴 ( Strategy Pattern )](https://victorydntmd.tistory.com/292)

  [저는 전략 패턴이 처음이라니까요?](https://joel-dev.site/75)

  [DI (Dependency Injection)가 뭘까?](https://siyoon210.tistory.com/122)

✔옵저버 패턴

---

: 객체의 상태 변화를 관찰하는 관찰자들, 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 각 옵저버에게 통지하도록 하는 디자인 패턴

• 옵저버 패턴에서는 주체 객체와 상태 변경을 알아야 하는 관찰 객체가 존재하며 이들의 관계는 1:1 혹은 1:N이 될 수 있다.
• 장점
  • 실시간으로 한 객체의 변경사항을 다른 객체에 전파할 수 있다
  • 느슨한 결합으로 시스템이 유연하고 객체간의 의존성을 제거할 수 있다
• 단점
  • 너무 많이 사용하면, 상태 관리가 힘들 수 있다
  • 데이터 배분에 문제가 생기면 자칫 큰 문제로 이어질 수 있다

// 옵저버들을 등록, 갱신하기 위함
public interface Publisher {
  public void registerObserver(Observer observer);
  public void removeObserver(Observer observer);
  public void notifyObservers();
}

public interface Observer {
  public void update(String title, String news);
}

public class NewsPublisher implements Publisher{
  private ArrayList<Observer> observers;
  private String title;
  private String news;
  
  public NewsPublisher() {
    observers = new ArrayList<>();
    title = null;
    news = null;
  }
  
  @Override
  public void registerObserver(Observer observer) {
    observers.add(observer);
  }
  @Override
  public void removeObserver(Observer observer) {
    int index = observers.indexOf(observer);
    observers.remove(index);
  }
  @Override
  public void notifyObservers() {
    for(Observer observer : observers) {
      observer.update(title, news);
    }
  }
  
  public void setNews(String title, String news) {
    this.title = title;
    this.news = news;
    notifyObservers();
  }
}

public class NewsSubscriber implements Observer{
  private String observerName;
  private String news;
  private Publisher publisher;
  
  public NewsSubscriber(String subscriber, Publisher publisher) {
    this.observerName = subscriber;
    this.publisher = publisher;
    publisher.registerObserver(this);
  }
  
  @Override
  public void update(String title, String news) {
    this.news = title + "!!! " + news;
    display();
  }
  
  private void display() {
    System.out.println("=== " + observerName + " 수신 내용 ===\n" + news + "\n");
  }
}

public class ObserverPatternMain {
 
  public static void main(String[] args) {
    NewsPublisher newsPublisher = new NewsPublisher();
 
    NewsSubscriber newsSubscriber1 = new NewsSubscriber("옵저버1", newsPublisher);
    NewsSubscriber newsSubscriber2 = new NewsSubscriber("옵저버2", newsPublisher);
 
    newsPublisher.setNews("특보", "옵저버 패턴이 만들어졌습니다.");
    newsPublisher.setNews("정정", "옵저버 패턴으로 내용이 정정됨을 알립니다.");
    
    newsPublisher.removeObserver(newsSubscriber1);
    newsPublisher.setNews("속보", "누군가 구독 해제를 했습니다.");
  }
 
}

=== 옵저버1 수신 내용 === 
특보!!! 옵저버 패턴이 만들어졌습니다. 

=== 옵저버2 수신 내용 === 
특보!!! 옵저버 패턴이 만들어졌습니다. 

=== 옵저버1 수신 내용 === 
정정!!! 옵저버 패턴으로 내용이 정정됨을 알립니다. 

=== 옵저버2 수신 내용 === 
정정!!! 옵저버 패턴으로 내용이 정정됨을 알립니다. 

=== 옵저버2 수신 내용 === 
속보!!! 누군가 구독 해제를 했습니다.