• “상속으로 추가”는 OCP를 잘 따르는 것 같지만, 조합 수만큼 서브클래스 필요, 캡슐화를 약화시킴

• 객체의 구성 관계 (합(Composition) 관계)+ 위임으로 기존 클래스 동작을 가볍고 유연하게 동적 확장
  - 데코레이터 패턴의 두 가지 구성 요소 : componet 클래스 , 확장 기능이 담긴 데코레이터

• 데코레이터 객체가 component를 재귀적으로 래핑
  
  

• BaseDecorator를 공통 부모로 해서 SMSDecorator, FacebookDecorator, SlackDecorator를 만들고, 기능을 추가하고 싶을 때는 조합별 클래스를 새로 만드는 대신 필요한 데코레이터 객체를 순서대로 감싸서 붙인다.

  public interface Notifier {
      public void send(String message);
  }
  --------------------------------------------------------------------
  public class BaseDecorator implements Notifier {
      private Notifier notifier;
  
      public void send(String message) {
          // 기본 메시지 로직
      }
  }
  --------------------------------------------------------------------
  public class SMSDecorator extends BaseDecorator {
      public SMSDecorator(Notifier notifier) {
          super(notifier);
      }
  
      public void send(String message) {
          message += "SMS Format message";
          super.send(message);
      }
  }
  --------------------------------------------------------------------
  BaseDecorator base = new SMSDecorator(new FBDecorator(new BaseDecorator()));
  base.send(message);
  
  // SMS -> FB -> 최종 전송

3.7 팩토리 메소드(Factory Method) 패턴

• 일반적인 클래스의 유형이 필요한지는 알고싶지만 구체적인 클래스 유형이 생성되는지는 모르거나 신경쓰고 싶지 않을 때 이용!
• 객체 생성 책임을 분리해 생성 변화에 대비
• 팩토리 메소드(createProduct)를 가진 추상 Creator 정의
• 팩토리 메소드 솔루션
  1. 최상위 공장 클래스(Creator)로서, 팩토리 메서드를 추상화(createProduct)하여 서브 클래스로 하여금 구현을 위임
  2. 각 서브 공장 클래스들(ConcreteCreator)은 이에 맞는 제품 객체를 반환하도록 생성 추상 메서드(createProduct)를 재정의
  3. 제품 구현체를 추상화(Product)
  4. 실제 제품 구현체(ConcreteProduct)
  
  
  
  

3.8 추상 팩토리(Abstract Factory) 패턴

• 구체 클래스 지정 책임을 분리하기 위해 추상 인터페이스로 관련 객체 패밀리 생성
• 팩토리 메소드 패턴과의 차이점
  • 추상 팩토리 패턴은 객체의 패밀리(부품 객체의 집합체)를 작성하도록 설계되었다.

• 추상 팩토리 패턴 솔루션
  1. 최상위 공장 클래스(AbstractFactory)로 여러 개의 제품들을 생성하는 여러 메소드들을 추상화
  2. 서브 공장 클래스(ConcreteFactory)들은 타입에 맞는 제품 객체를 반환하도록 메소드들을 재정의
  3. 각 타입의 제품들을 추상화한 인터페이스(AbstractProduct)
  4. 각 타입의 제품 구현체들로 이들은 팩토리 객체로부터 생성(ConcreteProduct)

“서로 관련 있는 객체들을 세트로 묶어서 생성하게 해주는 패턴”

• 의자만 따로 만들고
• 소파만 따로 만들고
• 테이블만 따로 만드는 게 아니라

“빅토리안 스타일 가구 세트”, “모던 스타일 가구 세트”
처럼 같은 계열의 객체들을 한꺼번에 맞춰서 생성

같은 종류의 제품(Chair) 안에도 스타일별 구현체가 여러 개 있을 수 있다.

• FurnitureFactory : 추상 팩토리 인터페이스
  • createChair()
  • createCoffeeTable()
  • createSofa()
• VictorianFurnitureFactory
• ModernFurnitureFactory

이제 제품 하나만 만드는 게 아니라 서로 관련된 제품 묶음을 한 번에 만드는 공장을 만든다.

실제 예시

• Windows용 버튼/체크박스 세트
• Mac용 버튼/체크박스 세트
• Application은 추상 팩토리에만 의존

제품군

• Button
• Checkbox

스타일(운영체제 계열)

• WinButton, WinCheckbox
• MacButton, MacCheckbox

클라이언트

• Application

추상 팩토리

• GUIFactory
  • createButton()
  • createCheckbox()

구체 팩토리

• WinFactory
• MacFactory

public class Demo {

    /**
     * Application picks the factory type and creates it in run time (usually at
     * initialization stage), depending on the configuration or environment
     * variables.
     */
    private static Application configureApplication() {
        Application app;
        GUIFactory factory; //내가 원하는 형태의 GUI를 GUIfactory를 통해서 결정
        String osName = System.getProperty("os.name").toLowerCase();

        if (osName.contains("mac")) { //MAC이면 Mac에 맞는 팩토리를 만듦
            factory = new MacOSFactory();
        } else {
            factory = new WindowsFactory();
        }

        app = new Application(factory);
        return app;
    }

    public static void main(String[] args) {
        Application app = configureApplication();
        app.paint();
    }//GUI를 세분화해서 표현
}

3.9 상태(State) 패턴

• 상태에 따라 객체 동작이 바뀌는 경우, Context와 State를 분리해 유연성 확보

Context는 initialState로 시작하고, state에 따라 상태가 바뀐다.
클라이언트는 Context를 사용할건데, ConcreteState를 만든다.
State는 여러개의 상태로 이루어져 있고, 각각의 doThis와 doThat로 여러 액션을 할수가 있다.
ConcreteStates는 여러 개의 context로 이루어짐

• 데스크탑 애플리케이션의 Document 클래스
• Document의 state : Draft(초안), Moderation(검토), Publish(출판)
  • 초안인 경우 상태를 검토로 이동한다.
  • 검토 상태에서는 현재 사용자가 관리자인 경우에만 문서를 출판할 수 있다.
  • 게시에서는 아무것도 하지 않는다.

상태 패턴을 이용한 Document 사례

내가 스테이트를 넣으면 그 스테이트에 따라 내가 멀 할 수 있는지 정해진다.

즉, 복잡하게 스위치 문이나 케이스문을 사용안할 수 있다.

//1. 상태 패턴 적용 전: 문자열 + switch로 상태 관리
public class Document {
    private String state;

    public Document() {
        state = "draft";
    }

    public void publish() {
        switch (state) {
            case "draft":
                moveToModeration();
                break;
            case "moderation":
                approveForPublication();
                break;
            case "published":
                break;
        }
    }

    private void moveToModeration() {
        state = "moderation";
        System.out.println("Document moved to moderation status.");
    }

    private void approveForPublication() {
        state = "published";
        System.out.println("Document approved for publishable status.");
    }
}

//2. 상태 패턴 적용 후
interface DocumentState {
    void publish(Document document);
}

class DraftState implements DocumentState {
    @Override
    public void publish(Document document) {
        System.out.println("Document moved to moderation status.");
        document.setState(new ModerationState());
    }
}

class ModerationState implements DocumentState {
    @Override
    public void publish(Document document) {
        System.out.println("Document approved for publishable status.");
        document.setState(new PublishedState());
    }
}

class PublishedState implements DocumentState {
    @Override
    public void publish(Document document) {
        System.out.println("The document has already been published.");
    }
}

public class Document {
    private DocumentState state;

    public Document() {
        this.state = new DraftState();
    }

    public void publish() {
        state.publish(this);
    }

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

상태 패턴은 객체의 현재 상태에 따라 같은 요청이라도 다르게 동작하도록,
상태를 별도의 클래스로 분리해서 관리하는 패턴이다.

상태 패턴 연습

예제: 스마트폰의 미디어플레이어

상태:

• PLAY
• PAUSE
• STOP

역할 매핑

• MediaPlayer → Context
• State → PlayerState
• ConcreteState → PlayingState, PausedState, StoppedState

1. State 인터페이스

interface PlayerState {
    void play();
    void pause();
    void stop();
}

2. ConcreteState 구현

class PlayingState implements PlayerState {
    @Override
    public void play() {
        System.out.println("Already playing");
    }

    @Override
    public void pause() {
        System.out.println("Pausing music");
        // Pause playback logic
    }

    @Override
    public void stop() {
        System.out.println("Stopping music");
        // Stop playback logic
    }
}

class PausedState implements PlayerState {
    @Override
    public void play() {
        System.out.println("Resuming playback");
        // Resume playback logic
    }

    @Override
    public void pause() {
        System.out.println("Already paused");
    }

    @Override
    public void stop() {
        System.out.println("Stopping music");
        // Stop playback logic
    }
}

class StoppedState implements PlayerState {
    @Override
    public void play() {
        System.out.println("Starting playback");
        // Start playback logic
    }

    @Override
    public void pause() {
        System.out.println("Can't pause when stopped");
    }

    @Override
    public void stop() {
        System.out.println("Already stopped");
    }
}

3. Context 클래스

class MusicPlayer {
    private PlayerState currentState;

    public MusicPlayer() {
        this.currentState = new StoppedState();
    }

    public void play() {
        currentState.play();
    }

    public void pause() {
        currentState.pause();
    }

    public void stop() {
        currentState.stop();
    }

    public void setState(PlayerState newState) {
        this.currentState = newState;
    }
}

4. Client 코드

public class Client {
    public static void main(String[] args) {
        MusicPlayer player = new MusicPlayer();

        player.setState(new PlayingState());

        // Play music
        player.play();

        // Pause music
        player.pause();

        // Stop music
        player.stop();
    }
}

- MusicPlayer는 현재 상태 객체(PlayerState)를 가지고 있다.
- play(), pause(), stop() 요청이 들어오면 현재 상태 객체에 위임한다.
- 현재 상태가 PlayingState인지, PausedState인지, StoppedState인지에 따라 동작이 달라진다.

관련 패턴: 전략(Strategy) 패턴

• 알고리즘(전략)을 분리하고 상황에 따라 선택 가능
• 각 전략 간에는 전환이 가능한 것이지, 연관 관계가 있는건 아니다.
• 장점: OCP 적용 가능, 알고리즘 분리, 동적 선택
• 단점: 전략이 소수면 구조가 과해질 수 있음, 클라이언트가 적절한 전략을 알아야 함

상태 vs 전략

• 상태: 상태 간 의존/전환 관계가 존재
• 전략: 전략 간 전환/의존 관계 없음

3.10 옵서버(Observer) 패턴

• 데이터를 보관하고 있는 Subject가 그 데이터를 이용하는 옵서버와 효과적으로 통신하면서 느슨하게 결합
• Subject 클래스
  • 옵서버 목록을 유지, 변경을 고지
  • 옵서버를 보고 있고, 옵서버가 변경이 있으면 알아채림
• Observer 클래스
  • 변경을 통지 받고 접근을 요청

Editor는 Manager로 구성되고,
EventManager는 여러 Listener로 구성된다.
Editor는 파일을 열고 저장하는 본래 기능에 집중하고,
이벤트와 관련된 처리는 EventManager에 일임한다.
EventManager는 등록된 EventListener들에게 알림을 보내고,
각 Listener는 update()를 통해 실제 작업(이메일 전송, 로그 기록 등)을 수행한다.
즉, 이런 구조를 통해 객체들이 느슨하게 연결된다.

4 아키텍처 평가(Architecture Evaluation)

아키텍처 평가란?

• 아키텍처/패턴의 속성, 강점, 약점을 결정하는 방법
• 선택한 아키텍처가 기능·비기능(품질) 요구를 충족함을 보증
• 방법: SAAM, ATAM

SAAM

• 시나리오 기반 평가
• 아키텍처가 시나리오를 실행 가능한지 판단
• 불가능하면 시나리오를 지원하도록 아키텍처 변경
• 시나리오 유형
  • 직접: 시스템 변경 불필요한 시나리오
  • 간접: 시스템 변경 필요한 시나리오(기능 추가/원하지 않는 기능 삭제)

ATAM

• 여러 품질 속성에 초점을 맞춰 평가하여 아키텍처 Trade-off(타협점)을 찾아냄
  

“중간고사 범위는 여기까지”

절대평가: 95점 A+/90점 A0