1

私の状況でより良い解決策は何ですか、クラスがあまり結合されないようにクラスを設計する方法は何ですか？

いくつかの機能を提供するライブラリ（API）があります（たとえば、subscribeメソッドを使用してFX価格のストリーミングをサブスクライブします）。APIクライアントがあります。APIクライアントは、取得したい価格をAPIに通知します。APIは、メソッドを使用したいくつかのインターフェース（たとえばSubscriptionStatus）でフィードバックを提供しますSubscribeSuccess(Subscription) and SubscribeFailed(Subscription)。APIクライアントには、アクティブなサブスクリプションのリストがあります（List<Subscription> activeSubscriptions）。そして、APIクライアントがサブスクリプションの成功にのみ反応するようにしたい（サブスクリプションをリストに追加するだけ）。その他の場合-メッセージを印刷してログに記録するだけです。サブスクリプションリスナーとAPIクライアント間の関係を整理するための最良の方法は何ですか？オプションは次のとおりです。

  1. APIクライアントインスタンスをサブスクリプションリスナーに渡して、呼び出すことができるようにしますapiClient.addSubscription(subscription)
  2. APIクライアントは、実装SubscriptionStatusインターフェイスを実装し、それらのイベントを管理します（失敗、内部で成功：activeSubscriptions.add（subscription））。対照：アクションには多くの種類があり、すべてのアクションには独自のリスナーがあります。したがって、Apiクライアントは非常に大きなクラスになります。
  3. 1つのメソッドで独自のインターフェースを定義SubscriptionSuccess(subscription)し、APIクライアントに実装させますか？
  4. あなたのオプション？

トピックについての考えは大歓迎です！

ありがとう！

4

2 に答える 2

1

私はオプション2に行きます。SubscriptionStatusインターフェイスが本当に大きく、一部のクライアントがその一部のみを実装したいことがわかっている場合は、ベースの空のスーパークラスを提供し、クライアントにそれを拡張させることができます（強制abstract的に）

そのようなBaseSubscriptionStatusものには、すべてのメソッドの空の実装があり、ユーザーが必要なものをオーバーライドできるようにします。別のオプションは

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

空の実装ではなく、基本メソッドごとに。

もちろん、SubscriptionStatus適切な依存性注入とテスト容易性のためにインターフェースを維持することができますが、BaseSubscriptionStatusそれを実装するだけです。

于 2012-01-23T16:50:16.103 に答える
0

私はオプション2で行きます。これにより、最終用途に最も柔軟性が与えられ、状況に応じてストリーミングの問題により効果的に対応できるようになります。

于 2012-01-23T16:46:13.903 に答える