Tightly Coupled classes: what is better design in my situation

Question

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:

1. Pass API client instance to the subscription listener so it can call apiClient.addSubscription(subscription)
2. API client implement implement SubscriptionStatus interface 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.
3. Define own interface with one method SubscriptionSuccess(subscription) and let API client implement it?
4. Your option?

Any thoughts on topic are appreciated!

Thanks!

Answer 1

I would go option 2, with a catch. If the SubscriptionStatus interface 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 it abstract to force them)

Something like BaseSubscriptionStatus that has empty implementations for all methods, and let the user override the ones it wants. Another option is to

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

for each base method instead of the empty implementation.

Of course, you can keep the SubscriptionStatus interface for proper dependency injection and testability, only make BaseSubscriptionStatus implement it.