Android: perché utilizzare un'interfaccia considerata la migliore pratica di comunicazione tra attività e frammento?

Question

In questa documentazione "Communicating with Other Fragments", Google ci dice che la migliore procedura per comunicare attività e frammenti è di implementare un'interfaccia. Questa interfaccia può quindi essere chiamata da Fragment e per eseguire il comportamento necessario in Activity.

Ma c'è anche un modo per farlo. Ottenere direttamente l'attività con il metodo "getActivity()" e quindi è possibile utilizzare tutto il "metodo pubblico" "".

Questo mi confonde parecchio. Perché non potevo davvero pensare ad alcuno svantaggio critico nell'usare il modo Hack per farlo.

Quello che il vantaggio di primo approccio è venuto nella mia testa sono:

1. posso limitare la "accessibilità risorsa" sotto la mia attività. Ma poiché Fragment è in grado di chiamare "getActivity()", può effettivamente accedere a tutti i metodi "pubblici" al suo interno. Quindi questo non può davvero convincermi.
2. Più leggibile e narrativo nel codice. Con il primo approccio, il codice ci dice che "questa attività apre solo questa specifica area accessibile per il frammento". Possiamo sapere "Cosa all'interno del frammento può interferire con l'attività" direttamente semplicemente guardando il codice nell'attività. Oppure, dovremo aprire il codice sotto Fragment per vedere cosa ha fatto.

Va bene, dopo averli riassunti, ero un po 'convinto da solo. Ma sinceramente, voglio davvero un altro solido e devo ragionare per farlo. Qualsiasi idea o documentazione sarebbe davvero apprezzata !!

Answer 1

Soprattutto, il vantaggio principale è la modularità del codice. Quando chiamate direttamente la vostra classe "genitore" dalla classe "figlio", create uno cyclic dependency. Questo significa in effetti che non puoi sostituirne uno, senza cambiare l'altro. Questo approccio spesso porta a un codice spaghetti difficile da mantenere, ancora più difficile da estendere e quasi impossibile da sostituire senza grandi sforzi di refactoring.

Per quanto riguarda il tuo esempio: se si chiama i metodi pubblici del vostro Activity direttamente dal Fragment, non sarà in grado di riutilizzare il vostro Frammento in altre attività senza l'implementazione di soluzioni hacky (come if(getActivity() instanceof A) {...} else {...}), né è possibile scambiare la tua attività per es una classe controller o qualsiasi altra soluzione che si presenta.

Se hai difficoltà a comprendere questo argomento, ti consiglio vivamente di leggere il libro Effective Java.

Answer 2

Non c'è un "vantaggio" insito in questo approccio, diverso da quello

• si tratta di un linguaggio riconoscibile. L'uso delle interfacce è il modo comune in che due classi comunicano tra loro in Java.
• lo stesso codice può essere riutilizzato in molti diversi Fragment s & Activity s.
• segue i principi generali di astrazione modularità &, in cui il Fragment "indica" allo Activity di aver raggiunto un determinato stato e lo Activity determina il proprio comportamento in relazione a questo stato.

Answer 3

Penso che il vantaggio di maggioranza dell'approccio basato sull'interfaccia sia dovuto alla sua ben nota e leggibile modularità e al livello di astrazione abbastanza alto come il punto di vista dell'ingegneria del software.

Supponete di essere a un lavoro di squadra e che ciascun compagno di squadra sia responsabile di uno di questi componenti, ad esempio, si supponga di dover implementare tale frammento e io dovrei implementare tale attività. Quindi, poiché siamo troppo distanti l'uno dall'altro, dovremmo concordare su un'interfaccia condivisa come standard tra di noi e quindi dovremmo implementare i nostri componenti che rispettano lo standard, in questo caso la nostra interfaccia concordata. Anche in considerazioni di ingegneria del software di un sistema software basato componente consiste di un numero di componenti che agiscono indipendentemente una dall'altra e le loro interazioni è fatto solo da interfacce condivise standard e materiali all'interno ogni componente è trasparente agli altri

Pertanto nel case, Activity e Fragment devono essere considerati come due componenti separati e ognuno dei quali non conosce i dettagli sull'altro. E qui arriva l'interfaccia Java.