[Chapter03] 역할이 여러 개인 객체?

[pythonstrup]

역할이 여러 개인 객체

• 책에서는 하나의 역할에 대해 여러 개의 객체가 구현된 예시만 볼 수 있었던 것 같아요!
• 스프링 이벤트를 공부하다가 ApplicationContext라는 인터페이스를 접하게 되었어요!
  • 해당 인터페이스의 구현체는 빈 탐색과 등록, 리소스 처리, 이벤트 관리 등 여러 역할을 가지고 있더라고요?

public interface ApplicationContext extends 
    EnvironmentCapable, 
    ListableBeanFactory, 
    HierarchicalBeanFactory,
    MessageSource, 
    ApplicationEventPublisher, 
    ResourcePatternResolver {...}

여기서 질문

• 여러 분들은 역할이 여러 개인 객체에 대해 어떻게 생각하시나요?

  • 바람직하지 않은 구조로 보시나요? 역할에 따라 객체를 분리해야 한다고 생각하시나요?
  • 아니면 때에 따라 역할이 여러 개인 객체도 필요하다고 생각하시나요?

• 왜 ApplicationContext은 여러 역할은 가진 객체로 만들어졌을까요?

  • ApplicationContext에서 구현된 역할들이 공유해야만 했던 자원들이 많아서 그랬던 걸까요? (구현을 편하게 하기 위해)

[JisuPark-dev]

저도 역할 파트 개념공부할때, 하나의 역할에 여러 배역이 있을 수 있다는 건 이해가 됐는데, 하나의 객체가 여러 역할을 가지고 있다는게 코드상으로 어떻게 나타나는지 모르고 있었다가 이번에 읽으면서 어느정도 느낀바가 있었습니다.

가령 (역할은 객체의 페르소나다) 질문에서 밸이 말씀하신 진료 프로세스의 web, app request를 예로 들어볼게요. ReservationJob이 웹과 앱 진료 모두를 수행해야한다면, implement WebRequest, AppRequest를 통해서 둘의 역할 모두를 수행하는게 그 예가 될 것 같습니다.

이렇게 보면 하나의 객체가 여러개의 역할을 수행하는게 충분히 필요할 수 있다고 생각이 들었어요.

여기에서 더 나아가서, 밸은 webRequest에 대한 구현체와 AppRequest에 대한 구현체를 따로따로 구현할것이지에 대한 질문을 해주신 것 같은데요.

우선은 저번시간에 저희가 같이 이야기한 트레이드오프가 생각이 났어요. 유연성이냐을 가지면서 복잡도를 높일 것이냐, 덜 유연하더라도 덜 복잡하게 갈 것이냐의 차이일 것 같아요. 하지만 만약 유연성을 높이는 선택을 한다면 어떤 기준에서 그렇게 해야할지는 같이 이야기해보면 좋을 것 같아요.

[JisuPark-dev]

저는 개인적으로는 reservationJob을 예시로 든다면, 하나의 객체에 두개의 역할을 지게 할 것 같습니다. 저번시간에 이야기할 때, 상속한다는 것은 상속한 객체의 인터페이스를 그대로 가지고 있음을 보장하는 것에 의미가 있다고 했잖아요. 그래서 reservationJob이 web request, app request 둘 다 역할을 수행하고 있다 (=관련 메서드, 기능을 제공한다)는 의미에서 사용하고 싶기 때문에 두게 다 상속시킬 것 같아요.

같은 논리로 ApplicationContext도 하위의 여러 가지를 상속하는 것이 '내가 ~~ 기능들 모두 제공해'라고 말해주는 것이라서 바람직해보입니다.

[JisuPark-dev]

설계와 구현은 돌고도는 사이클이다.