📜 제목으로 보기

패턴을 배우는 순서

  • 패턴을 배우는 순서

    • 좋은 상속의 Templatemethod 패턴

    • 좋은상속이라도 조합폭발방지 -> strategy패턴

      • 전략패턴의 전략패턴 -> adapter 패턴
    • 전략객체가 많이 나오다보면, 단일요소 객체 vs 컬렉션 객체를 포괄하는Composite패턴
      • element vs collection -> 컴포짓 패턴

    • Composite객체의 출력을 위한 구상class 속 loop등의 제어문들을 타는 객체를 따로 외부에 위임 -> Visitor패턴

      • 제어문을 타야 자신의 데이터를 다 뿌릴 수 있는 객체(Composite객체)가 있다고 치자

        • 제어문을 가진 체 출력하는 Renderer클래스가 있다

        • 제어문의 안에 내용만 바뀐다면 [종류별 XXXXRenderer클래스들]을 여러개 만드는 대신 제어문을 역전하여 유지만 하고, 제어문 안의 내용은 Visitor를 주입해서 끼워넣은 다음, 전략패턴으로서 종류별 XXXXVisitor를 만들어서 끼워넣자

          • 제어문은 전략패턴으로 못만든다. 제어문 속에서 라이프싸이클별 작동하는 로직을 전략패턴으로 뺀 다음 Visitor로 이름 붙인다.

            image-20220811165813062

        • 이제 제어문 속 라이프싸이클을 타는 visitor별로 실제 제어대상 객체(Composite객체)를 제어역전된 클래스(Renderer의 메서드 인자 -> Visitor의 메서드인자(역할위임)을 통해 Visitor에게 전달한다

          image-20220811170028065

      • visitor를 주입받는 구상클래스(Renderer) 자체가 제어의역전 클래스임. Visitor객체 는 제어역전된 속에서 제어문만 탄다

      • 실제 컴포짓객체 속 데이터를 반환해주는 것은, Visitor의 역할책임으로 위임

        • 데이터자체는 Composite객체가 VIsitor의 역할/책임 메서드의 파라미터로 들어가서 사용됨

    • element간에 연결 by linkedlist -> 데코레이터 패턴

    • 중간에 멈출 수 없는 한번에 쭉 가는 for문을 써야한다는 문제점 -> 책임사슬 패턴

    • 나머지들 -> 끝판왕 커맨드 패턴
      • Visitor주입으로 인한 제어의역전 이후에 행위도 캡슐화한 뒤 역전하는 Command패턴
      • 이미 존재하는 composite 객체를 소유한 Command홀더 객체내에서 만들어간다
        • 지연실행에 대한 일이라 어렵다
        • 해야하는 일을 함수에 담아서 -> 객체로 만들고 -> 모았다가 -> 실행or역카운터실행
      • 제어에 참여하는 객체(Visitor가 파라미터로 위임받은 객체)를 소유한 커맨드홀더객체를 만들고 1개의 메서드(with 서비스메서드들) + 여러 구상커맨드객체들로 런타임에서 행위를 조작할 수 있는 범용객체가 된다.
        • Visitor에 위임하는 객체를, 커맨드홀더가 소유함으로써 커맨드객체를 통한 행위조작으로 의존성없는 안전한 범용객체가 Visitor에게 역할 위임하게 되어 Visitor도 안전해진다.
        • 행위를 추가하려면, 커맨드객체 추가해서 처리하면 되니까??
      • 커맨드홀더객체는, 범용객체로서, runtime에 행위위임 커맨드객체를 교체해서 갈아낄 수 있게 된다.
        • xml에는 string으로 -> 주입돌 커맨드들을 설정하는 것이고, 스프링빈즈가 runtime에 조립한다.
        • @autowired애노테이션 -> 범용객체 생성 후, @달린 것들을 끼워넣어서 돌아가게 한다.
        • 커맨드홀더객체 == 커맨드invoker == 범용객체 == composite라면 root객체를 소유한 객체?!

    • 저장하고 로드하려면 -> 메멘토 패턴

      • 메멘토패턴은 visitor패턴을 통해 쉽게 구현할 수 있다.

        • 구상 visitor 중 1개(JsonVisitor)가 라이프싸이클을 타면서 처리된 내용을 매번 객체context인 필드에 저장해놓는다.

          • 이 때, 이미 외부에서 생성된 Visitor를 주입해야한다
          • 다른 Visitor는 내부 지연생성도 할 수 있도록 주입대상인 Renderer는 factory 함수형인터페이스를 생성자로 받는다.

          image-20220812163436350

        • save를 구현하는 곳에서는 상태값에 데이터정보를 저장한 상태이므로 getter로 제공받아 저장한다.

      • 메멘토패턴은 Visitor패턴계열이다.
        • 일단 Composite패턴 -> 출력을 위한 Visitor패턴을 구현할 줄 알아야 구현된다.
      • 참고로 Command패턴은 다른 동네이다
        • bridge, adapter, command패턴이 한 동네이다.
        • 행위를 포장하는 것이 더 큰 동네이고 힘들다
      • @Transactional을 하려면, 메멘토패턴으로 상태를 저장해야한다.
        • undo/redo를 할 수 있다. 트랜잭션으로서 롤백을 할 수 있다.
        • 내가 만든 메소드도 롤백할 수 있게 된다.
    • 동네 구분
      • Visitor계열: strategy -> composite + visitor -> 전체의 40%
      • command계열: bridge, adapter 등 -> 나머지 전부
    • composite + visitor가 자유로우면 중급개발자이다.
  • 1패턴 -> 1객체가 아니라 1객체가 여러가지 패턴을 소유할 수 있음.
    • 분산되어있는 컴포짓패턴 -> 다음장에 바로 컴포짓패턴의 3가지 역할을 다 수행하는 컴포짓패턴을 소개함.
    • 디자인패턴의 다이어그램은, 객체의 역할이지 객체가 아니다.
      • 다이어그램 갯수만큼 객체가 나오지 않는다.
    • 역할별로 1개의 객체로 연습
    • 이후 모든 역할을 1개의 객체에 몰빵하는 연습
      • 전략객체이자 실행객체
      • 전략객체이자 상태객체
      • 전략객체 소유하는 객체를 상태객체로 만들기