Classi strettamente accoppiate: cosa è meglio progettare nella mia situazione

Question

Qual è la soluzione migliore nella mia situazione, come progettare le lezioni in modo che non siano molto accoppiate?

Ho una libreria (API) che fornisce alcune funzionalità (ad esempio, iscriviti per lo streaming di prezzi FX con subscribe metodo). Ho un cliente API, che racconta all'API quali prezzi vuole ottenere. API fornisce feedback con alcune interfaccia (ad esempio SubscriptionStatus) con metodi SubscribeSuccess(Subscription) and SubscribeFailed(Subscription). Nel client API ho un elenco di abbonamenti attivi (List<Subscription> activeSubscriptions). E voglio che il client API reaggi solo sul successo dell'abbonamento (basta aggiungere l'abbonamento nell'elenco). In altri casi: basta stampare il messaggio per registrare. Qual è il modo migliore per organizzare le relazioni tra ascoltatore di abbonamento e client API? Le opzioni potrebbero essere:

1. Passa l'istanza del client API all'ascoltatore di abbonamento in modo che possa chiamare apiClient.addSubscription(subscription)
2. API Client Implement Implement SubscriptionStatus Interfaccia e gestire quegli eventi (Fail, successo internamente: ActiveSubScriptions.add (abbonamento)). Contra: ci sono molti tipi di azioni e ogni azione ha il suo ascoltatore .. quindi il cliente API sarà davvero una classe grande.
3. Definire la propria interfaccia con un metodo SubscriptionSuccess(subscription) E lasciare che il client API lo impletica?
4. La tua opzione?

Qualsiasi pensiero sull'argomento è apprezzato!

Grazie!

Answer 1

Andrei l'opzione 2, con una cattura. Se la SubscriptionStatus L'interfaccia è davvero molto grande e sai che alcuni clienti vogliono solo implementarla, puoi fornire una superclasse vuota di base e lasci che i clienti la estendano (fallo abstract per costringerli)

Qualcosa di simile a BaseSubscriptionStatus Ciò ha implementazioni vuote per tutti i metodi e consentono all'utente di scavalcare quelle che desidera. Un'altra opzione è di

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

Per ogni metodo di base anziché l'implementazione vuota.

Certo, puoi mantenere il SubscriptionStatus Interfaccia per la corretta iniezione di dipendenza e la testabilità, solo BaseSubscriptionStatus implementalo.

Answer 2

Andrei con l'opzione due. Ciò darebbe alla fine l'uso della massima flessibilità e sarebbe in grado di rispondere ai problemi con lo streaming in modo più efficace nella loro situazione.