Vantaggi dell'iniettare il bus di eventi Otto invece di usare il singleton statico

Question

Nelle mie app Android sto utilizzando Otto come bus eventi e Dagger per l'iniezione delle dipendenze.

Nell'userguide di Otto e in molti post del blog si consiglia di utilizzare l'iniezione per ottenere un autobus singleton. L'ho fatto per un po 'di tempo, ma ultimamente sto diventando più dubbioso se iniettare il bus abbia qualche vantaggio sull'uso di un semplice singleton statico.

Con l'iniezione devo iniettare ogni vista personalizzata o ViewHolder che voglio essere in grado di inviare eventi UI sul bus. Soprattutto con il pugnale sembra un po 'maldestro iniettare ogni classe in cui ho bisogno del bus. Certo, potrei passare il bus per metodo costruttore o setter, ma può essere anche un po 'goffo se pensi ad un adattatore con molti tipi di visualizzazione diversi, per esempio.

E non vedo alcun vantaggio nell'iniettare il bus. Nel caso di Otto viene iniettata un'implementazione concreta (un'istanza di Bus) che non cambierà mai. Avvolgere Otto per disaccoppiare non ha senso se pensi, a causa del modo in cui funziona l'abbonamento.

Quindi, qualcuno vede qualche vantaggio nell'iniezione di Otto che non vedo?

Answer 1

A mio parere, è necessario avvolgere definitivamente il bus eventi nella propria classe e utilizzare tecniche di iniezione dipendente per passarlo ai client.

Ci sono molti vantaggi di questo approccio rispetto ottenendo semplicemente un riferimento tramite una chiamata al metodo statico getInstance():

• le dipendenze diventano esplicite. Quando si ottengono riferimenti a oggetti tramite chiamate statiche, le dipendenze sono nascoste all'interno dell'implementazione dei client, il che rende il codice fragile e difficile da comprendere.
• Sarà più semplice passare a un'implementazione diversa del bus eventi se si presenta la necessità.
• Le dipendenze iniettate sono più facili da simulare nei test
• Il fatto che le tecniche di iniezione delle dipendenze introducano un certo grado di difficoltà è in realtà una buona cosa: se stai lottando, questo spesso indica che stai facendo qualcosa di sbagliato. Nel tuo caso, sospetto che tu stia abusando del bus degli eventi.

io dico che è possibile che si sta abusando bus evento perché io non vedo proprio il motivo per cui si avrebbe bisogno di avere un riferimento ad esso nella View sottoclassi. Immagino che tu invii notifiche sulle interazioni dell'utente al bus eventi, quindi sottoscrivi Activity o Fragment sul bus degli eventi per intercettare questi eventi. Event bus è uno strumento sbagliato in questo caso (anche se funziona alla grande).

Il motivo per cui event bus è uno strumento sbagliato in questo caso è perché Fragments e Activity possono avere accesso diretto agli oggetti View contenuti. È possibile ottenere i riferimenti a questi Views e registrare Fragments e Activities come ascoltatori. Non c'è bisogno di disaccoppiare nulla qui.

Al contrario: pensare a un caso in cui si va e refactoring il tuo Views in modo tale che nulla viene pubblicato sul bus di eventi più (ad esempio, i requisiti aziendali sono cambiati).Dal momento che le notifiche Views sono solo associate al numero Fragment o Activity tramite il bus degli eventi, è molto probabile che si dimentichi di rimuovere la logica di gestione degli eventi da Fragment e Activity, lasciando così il "codice morto". Questo diventa disordinato molto rapidamente.

La pratica migliore sarebbe usare design pattern Observer e lasciare Views notificare Activities e Fragments direttamente, e solo quando la manipolazione coinvolge un altro componente (che non può essere facilmente raggiungibile da Fragment e Activity; ad esempio un altro Fragment o Activity) sarà questi componenti postano eventi sul bus eventi. Se segui questo approccio, avrai bisogno di avere un riferimento al bus eventi solo in "componenti di primo livello", e non ci sarà alcun problema.

P.S. Ho recentemente pubblicato uno blog post which introduces some best practices for dependency injection in Android.