密接に結合されたクラス：私の状況でより良いデザインとは何か

Question

私の状況ではどのような解決策がありますか？

私はいくつかの機能を提供するライブラリ（API）を持っています（例えば、subscribeメソッドでストリーミングFXの価格を購読する）。私はAPIクライアントにAPIを教えてもらうことに決めました。 APIは、SubscribeSuccess(Subscription) and SubscribeFailed(Subscription)の方法でいくつかのインターフェイス（たとえばSubscriptionStatus）でフィードバックを提供します。 APIクライアントでは、アクティブなサブスクリプション（List<Subscription> activeSubscriptions）のリストがあります。そして、私はAPIクライアントがサブスクリプションの成功に反応することを望みます（リストにサブスクリプションを追加するだけです）。それ以外の場合は、ログに記録するだけです。 サブスクリプションリスナーとAPIクライアントの関係を整理する最良の方法は何ですか？ オプションは次のようになります。

1. パスAPIのクライアントインスタンスのサブスクリプション・リスナーにそれが（内部的に、成功を失敗：activeSubscriptions.add（サブスクリプション））をSubscriptionStatusインタフェースを実装し、それらのイベントを管理する実装apiClient.addSubscription(subscription)
2. APIクライアントを呼び出すことができますので、 。コントラ：たくさんの種類の行動があり、すべての行動はそれ自身のリスナです。だから、Apiクライアントは本当に大きなクラスになります。
3. 独自のインターフェイスを1つのメソッド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を使用します。これにより、最終的な柔軟性がエンドユーザに与えられ、ストリーミングに関する問題に対応できるようになります。