[Chapter03] 역할은 객체의 페르소나다.

[pythonstrup]

떠오른 아이디어

• 작년 이맘때쯤에 진료 프로세스를 전략 패턴으로 개선했었습니다.
  • 진료라는 역할을 인터페이스로 추상화하고, 각각의 세부사항[예약, 오프라인, 온라인 그 외 여러 진료 프로세스]을 구현체로 만들어 사용했습니다.
• 최근 스프링 이벤트를 공부하면서 ApplicationEventPublisher를 스프링이 어떻게 구현하는지 알게 되었어요.
  • ApplicationContext라는 인터페이스를 구현하는 구현체를 통해 ApplicationEventPublisher 인터페이스가 구현됩니다.
  • 여기에서 사용된 원리가 인터페이스 분리 원칙(Interface Segregation Principle)입니다.
  • ApplicationContext는 빈 탐색과 등록, 리소스 처리 등의 다양한 역할을 수행하는데요. 이벤트 발행을 위한 역할을 ApplicationEventPublisher를 인터페이스로 분리했기에 실제로 이벤트 관련 기능을 사용할 때 해당 기능만 따로 주입받아 사용할 수 있게 한 겁니다!

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

@Component
@RequiredArgsConstructor
public class OrderEventPublisher {

  private final ApplicationEventPublisher eventPublisher; // applicationContext 구현체 중 이벤트 발행 인터페이스만 주입

  public void publishOrderEvent(final Order order) {
    eventPublisher.publishEvent(OrderEvent.of(order));
  }
}

• 진료 프로세스에서 보면 Web 진료신청이라는 특수한 단계가 있었습니다. (지금도 있는지 모르겠네요.)
  • 어떤 구현체에서는 구현되지만 대부분의 진료 프로세스 구현체에서는 사용되지 않았던 것 같습니다.
• Web 진료신청이라는 특수한 역할을 따로 떼어내어 인터페이스로 만들어 따로 구현했다면 더 좋았을 거란 생각이 들었어요!
  • Web 진료신청이 필요한 프로세스는 해당 인터페이스를 구현합니다. (기존 인터페이스와 Web 진료신청을 위한 인터페이스 2개를 구현)
  • Web 진료를 구현하지 않아도 되는 구현체는 기존의 인터페이스 하나만 구현합니다.

결론

• 역할이 여러 개라고 판단된다면 굳이 하나의 인터페이스에 꾸겨 넣는 게 아니라 따로 분리해 구현하는 것이 좋은 선택이 될 수 있습니다!
• 그리고 ApplicationContext을 보니 역할이 여러 개인 객체가 있는 걸까? 하는 생각도 드네요?

[JisuPark-dev]

지금은 플라잉닥터에서는 hospitalJob이라는 인터페이스 아래, app, web 진료신청이 공존하는 형태네요! 예약과 오프라인 진료에서만 사용하고 있어서 말씀하신데로, 만약 인터페이스를 분리했더라면

@Override
    public void webRequest(HospitalJobDto hospitalJobDto, MultipartHttpServletRequest multipartHttpServletRequest) {
    }

이런 코드가 사라질 수 있지 않았을까 생각이 듭니다.