밀접하게 결합 된 수업 : 내 상황에서 더 좋은 디자인은 무엇입니까?

Question

내 상황에서 더 나은 해결책은 무엇이며, 수업을 설계하는 방법은 매우 어울리지 않습니다.

일부 기능을 제공하는 라이브러리 (API)가 있습니다 (예 : subscribe 메서드로 스트리밍 FX 가격에 가입). 나는 그것이 원하는 가격을 API에 알려주는 API 클라이언트를 가지고있다. API는 SubscribeSuccess(Subscription) and SubscribeFailed(Subscription) 메소드를 사용하여 일부 인터페이스 (예 : SubscriptionStatus)와 함께 피드백을 제공합니다. API 클라이언트에는 활성 구독 목록 (List<Subscription> activeSubscriptions)이 있습니다. 그리고 API 클라이언트는 구독 성공에 반응해야합니다 (목록에 구독 만 추가). 다른 경우에는 - 로그 할 메시지를 인쇄하십시오. 구독 청취자와 API 클라이언트 간의 관계를 구성하는 가장 좋은 방법은 무엇입니까? 옵션이 될 수있다 :

1. 패스 API 클라이언트 인스턴스 가입 리스너가 apiClient.addSubscription(subscription)
2. API 클라이언트가 SubscriptionStatus 인터페이스를 구현 구현 호출하고 해당 이벤트를 관리 할 수 ​​있습니다 (실패 성공 내부 : activeSubscriptions.add (가입)) . 콘트라 : 많은 종류의 행동이 있고 모든 행동에는 독자적인 청취자가 있습니다. 그래서 Api Client는 정말 큰 수업이 될 것입니다.
3. 하나의 메소드 SubscriptionSuccess(subscription)으로 인터페이스를 정의하고 API 클라이언트가 구현하도록 허용 하시겠습니까?
4. 옵션은 무엇입니까?

주제에 대한 의견을 보내 주시면 감사하겠습니다.

감사합니다.

Answer 1

나는 옵션 2를 잡을 것이다. SubscriptionStatus 인터페이스는 정말 정말 큰이며, 일부 클라이언트가 해당 부분을 구현하려는 알고 있다면, 당신은 기본 빈 슈퍼 클래스를 제공 할 수 있으며, 클라이언트는 같은

뭔가를 (이 abstract을 강제 할 수 있도록)를 확장 할 수 BaseSubscriptionStatus에는 모든 메소드에 대한 빈 구현이 있으며, 사용자가 원하는 메소드를 대체하도록하십시오. 또 다른 옵션은 빈 구현 대신 각 기본 메소드에 대해

throw UnsupportedOperationException("This method is not supported by your implementation of SubscriptionStatus. Please override it"); 

입니다.

물론 SubscriptionStatus 인터페이스에서 적절한 종속성 삽입 및 테스트 가능성을 유지할 수 있으며 BaseSubscriptionStatus 만 구현하면됩니다.

Answer 2

옵션 2를 사용합니다. 이렇게하면 최종 사용자가 가장 유연하게 사용할 수 있으며 상황에 따라 스트리밍 관련 문제에보다 효과적으로 대응할 수 있습니다.