紧耦合类：在我的情况下什么是更好的设计
对于我的情况，更好的解决方案是什么？如何设计类以使它们不是非常耦合？
我有一个库（API），它提供了一些功能（例如，使用 subscribe 方法订阅流式外汇价格）。我有一个 API 客户端，它告诉 API 它想要获得哪些价格。 API 通过 SubscribeSuccess(Subscription) 和 SubscribeFailed(Subscription) 方法通过某些接口（例如 SubscriptionStatus）提供反馈。在 API 客户端中，我有一个活动订阅列表 (List)。我希望 API 客户端仅对订阅成功做出反应（只需将订阅添加到列表中）。在其他情况下 - 只需打印消息到日志。 组织订阅侦听器和 API 客户端之间关系的最佳方式是什么？ 选项可以是：
- 将 API 客户端实例传递给订阅侦听器，以便它可以调用
apiClient.addSubscription(subscription) - API 客户端实现
SubscriptionStatus接口并管理这些事件（失败、成功）内部：activeSubscriptions.add(subscription))。 Contra：有很多类型的操作，每个操作都有它自己的侦听器。所以 Api Client 将是一个非常大的类。 - 用一个方法
SubscriptionSuccess(subscription)定义自己的接口并让API客户端实现它？ - 你的选择？
对主题的任何想法表示赞赏！
谢谢！
what is the better solution in my situation, how to design classes so they are not very coupled?
I have an Library (API) which provides some functionality (for example, subscribe for streaming FX prices with subscribe method). I have an API client, which tell to API which prices it want to get. API provides feedback with some interface (for example SubscriptionStatus) with methods SubscribeSuccess(Subscription) and SubscribeFailed(Subscription). In API client I have a list of active subscriptions (List<Subscription> activeSubscriptions). And I want API client only react on subscription success (just add subscription into list). In other cases - just print message to log.
What is the best way to organize relations between Subscription listener and API Client?
Options could be:
- Pass API client instance to the subscription listener so it can call
apiClient.addSubscription(subscription) - API client implement implement
SubscriptionStatusinterface and manage those events (fail, success internally: activeSubscriptions.add(subscription)). Contra: There are a lot of types of actions and every action has it's own listener.. So Api Client will be really big class. - Define own interface with one method
SubscriptionSuccess(subscription)and let API client implement it? - Your option?
Any thoughts on topic are appreciated!
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我会选择选项2，但有一个问题。如果 SubscriptionStatus 接口真的很大，并且您知道某些客户端只想实现其中的一部分，那么您可以提供一个基本的空超类，然后让客户端扩展它（使其成为抽象的） 来强制它们）
类似
BaseSubscriptionStatus的所有方法都有空实现，并让用户覆盖它想要的方法。另一种选择是为每个基本方法而不是空实现。
当然，您可以保留 SubscriptionStatus 接口以实现适当的依赖项注入和可测试性，只需让
BaseSubscriptionStatus 实现它即可。I would go option 2, with a catch. If the
SubscriptionStatusinterface is really really big, and you know some clients only want to implement part of that, you can provide a base empty superclass, and you let clients extend it (make itabstractto force them)Something like
BaseSubscriptionStatusthat has empty implementations for all methods, and let the user override the ones it wants. Another option is tofor each base method instead of the empty implementation.
Of course, you can keep the
SubscriptionStatusinterface for proper dependency injection and testability, only makeBaseSubscriptionStatusimplement it.我会选择第二个。这将为最终用户提供最大的灵活性，并能够在其情况下更有效地响应流媒体问题。
I would go with option two. This would give the end use the most flexibility and be able to respond to issues with the streaming more effectively in their situation.