Composite Pattern 이용해서 Components 분리하기

[helloheesu]

설계

Composite Pattern - 컴포넌트의 '묶음'만을 바라본다.

Component

공통 행동 인터페이스를 정의하는 상위 객체. 특정 페이지로 이동할 수 있고 화면 사이즈가 바뀌면 반영할 수 있다.

• container : 해당 객체에서 다루는 DOM Element.
• children : Composite Pattern 의 child 와 같은 존재.
• init() : 클래스 초기화 함수. 인터페이스로 정의된 내부 함수(_refineOption 등)를 호출하고 있음.
• _moveTo(), _prev(), _next() : controller에게 moveTo 이벤트를 발생시키기 위한 함수. clickHandler 등으로 쓰일 수 있음. _resize()는 부모에서 이벤트를 바로 참조할 수 있으므로 필요 없음.
• moveTo(), prev(), next(), resize() : 외부(controller 혹은 부모)에서 자식들을 일괄적으로 부르기 위한 공개 함수.
• this._moveTo -> this.controller.moveTo -> this.moveTo 순으로 불리게 됨

Controller

주요 데이터를 관리하는 객체. 현재 페이지 번호, 전체 페이지 수 등을 저장하고 다른 컴포넌트들에게 대답해준다.

장단점

장점

• 공통 인터페이스를 한 눈에 볼 수 있다
  • 각 컴포넌트가 하는 일이 적고 뻔해서 적합
• 특정 컴포넌트에게 일을 시킬 때, 자식의 종류나 수를 신경쓰지 않아도 된다
  • navigator, indicator 등 컴포넌트의 존재가 옵셔널한 상황이라 적합

단점

• 지금 당장의 코드에선 Projector 만 자식들을 가지고 있다
  • 기대보단 장점이 크지 않아보인다
  • navigator, indicator 도 더 분리할 예정
• 공통 인터페이스로 행동이 제한된다
  • 현재 요구사항에는 제한적인 행동뿐이다
  • 이 패턴으로 대응이 안 될 정도로 요구사항이 바뀌었으면 재설계는 당연한 게 아닌가..?

TODO

리팩토링

• [ ] projector - controller 분리
  • 역할이 모호해서 덜 분리된 것 같다. '주요' 데이터가 뭐지?
• [ ] components/ 로 묶기
• [ ] 컴포넌트별로 config 분리

demo 분리

• [ ] 소은님 커밋 반영
• [ ] scss, js 분리

테스트 작성

• TDD로 하고 싶었으나... 자꾸 실패해서 일단 구현부터
• [ ] import 안 됨
• html 로드가 안 됐던 것 같다

[hyeonmi]

controller 설명에 "주요 데이터"를 관리하는 객체라고 되어 있는데 constroller의 역할이 무엇이라고 생각하시나요?

[helloheesu]

Composite Pattern 은 잘못된 선택임을 깨달음.

• 컴포짓 패턴의 핵심 목표 : 리프-컴포짓의 구분을 없애고 '덩어리'로 일괄 취급하고 싶다! 참고
• 근데 이 라이브러리에선 그룹으로 취급할 게 별로 없음.

결국 다형성을 원했던 것 뿐이다.

• 네비게이터든 인디케이터든 옵셔널하게 추가/삭제될 수 있다른 점에 기인해서
• '컴포넌트 - moveTo 등의 일관된 인터페이스를 가진 객체'라고 묶고,
• 대상이 네비/인디인지 신경쓰지 않고 컴포넌트라고 일괄 취급하고 싶었음

다른 패턴들 비교 참고 1 2

• 데코레이터 패턴 : 한 클래스에 기능을 겹겹이 추가. 캐러셀 + 네비게이터블 + 인디케이터블. 기능을 옵셔널하게 추가한다는 점에서 어울려보이기도 한다. 하지만 각 부분들을 '컴포넌트'라고 독립적으로 관리하고 싶다면 부적절.
• 프록시 패턴 : 특정 컴포넌트를 직접 조작하지 못 하게 중간 다리(프록시)를 둠. 네비/인디를 직접 조작하지 않고 메인 클래스만 조작하기 때문에 헷갈릴 수 있다. 하지만 '의도'가 다름. 조작을 못 하는 것이 핵심이 아님.
• 어댑터 패턴 : '이미 완성된 제품'을 갖다쓸때, 마음에 안 드는 인터페이스가 있을 때 중간에서 조정하는 클래스(어댑터)를 둠. 캐러셀을 개발할 때 다른 라이브러리를 가져다 쓴다면 활용하겠지만, 컴포넌트 구현만 놓고보면 필요 없음. (참고 - 예시가 짱)
• 퍼사드 패턴 : 네비/인디를 신경쓰지 않고 하나만 신경써도 되도록 메인 클래스(퍼사드)를 둠. 보통 공개 라이브러리를 만들 때 외부에서 사용하기 쉽게 열어주기 위해 사용.

[helloheesu]

설계에서 (패턴을 사용해서) 얻고자 하는 것

1. (라이브러리 사용자가,) 여러 컴포넌트 클래스에 대해서 알 필요 없이, 옵션 전달 같이 간단히 조작만 알면 되게 하고 싶다 -> Facade Pattern (? Mediator Pattern?)
2. 각 컴포넌트를 개발할 때 다른 컴포넌트가 영향을 최대한 받지 않게 하고 싶다. -> 각 컴포넌트별 클래스 분리
3. 컴포넌트에 중복되는 동작을 묶어서 일관성을 유지하고 싶다. -> 상속
4. '현재 페이지' 같은 정보가 항상 동기화된다는 걸 보장하고 싶다. 컴포넌트 개발자가 신경을 많이 쓰지 않아도 보장하고 싶다. -> ??

필요한 역할들

• 라이브러리 사용자가 만날 얼굴
• 옵션에 따라 컴포넌트들 생성
• 동기화 보장
  • 컴포넌트간 데이터를 조정하는 방식일지, 데이터를 중앙화해서 혼자서 관리하는 방식일지는 고민.
• 컴포넌트들

[hyeonmi]

설계 패턴에서 1번에 퍼사드로 사용한다고 하면 사용자에게 제공할 공개 함수(기능)을 먼저 추려보는게 좋을거 같아요. 그리고 기우 일수 있으나 첨언을 하면... 내가 구현을 하려다 보니 이런 패턴이 필요해서 사용하게 됐어가 되어야 하는데 이런 패턴을 여기에 적용해 보자가 되면 디자인 패턴 중독에 빠질수 있어요.

[hyeonmi]

덕분에 Composite pattern 대해 다시 생각해 볼 기회가 됐네요~ 👍