Android. Почему использование интерфейса считается лучшей практикой общения между Activity и Fragment?

В этой документации "Общение с другими фрагментами" Google сообщает нам, что лучшей практикой для взаимодействия Activity и Fragment является реализация интерфейса. Затем этот интерфейс может вызываться Fragment и выполнять необходимое поведение в Activity.

Но есть и хак способ сделать это. Непосредственно получить действие методом "getActivity()", а затем мы можем использовать все "общедоступные методы" под ним.

Это меня очень смущает. Потому что я не мог придумать ни одного критического недостатка использования хакерского способа сделать это.

Какое преимущество первого подхода пришло мне в голову:

  1. Я могу ограничить "доступность ресурсов" своей активностью. Но поскольку фрагмент может вызывать «getActivity()», он может фактически получить доступ ко всем «общедоступным» методам в нем. Так что это не может меня убедить.
  2. Более читаемый и рассказывающий истории в коде. При первом подходе код говорит нам, что «это действие открывает только эту конкретную доступную область для фрагмента». Мы можем узнать «Что внутри фрагмента может помешать действию» напрямую, просто взглянув на код в действии. В противном случае нам нужно будет открыть код в Fragment, чтобы увидеть, что он сделал.

Хорошо, после того, как я резюмировал это, я немного убедился сам. Но, честно говоря, мне очень хочется какой-то другой солидной и обязательной причины для этого. Любая идея или документация будут действительно оценены!!


android java android-fragments android-activity interface
person KunYu Tsai    schedule 09.03.2015    source источник
comment
Есть много причин, по которым вы следует использовать интерфейсы, а не просто вызывать общедоступные методы. Просто погуглите.   -  person code monkey    schedule 09.03.2015
comment
@QuentinTsai: ты видел мой ответ?   -  person Y.S    schedule 15.03.2015
comment
@ZygoteInit Да! Извините за поздний ответ, я заболел раньше. Я просмотрел все ваши ответы, все они очень полезны. Но извините, я могу дать правильный ответ Рейньеру, потому что для меня это действительно напоминает мне то, чего я раньше не замечал. Спасибо всем !!   -  person KunYu Tsai    schedule 19.03.2015

Ответы (3)


arrow_upward
7
arrow_downward

Прежде всего, основным преимуществом является модульность вашего кода. Когда вы напрямую вызываете свой «родительский» класс из «дочернего», вы создаете циклическую зависимость. . Это фактически означает, что вы не можете заменить одно, не изменив другое. Этот подход часто приводит к спагетти-коду, который трудно поддерживать, еще сложнее расширять и почти невозможно заменить без значительных усилий по рефакторингу.

Что касается вашего примера: если вы вызываете общедоступные методы вашего Activity непосредственно из Fragment, вы не сможете повторно использовать свой фрагмент в других действиях без реализации хакерских решений (например, if(getActivity() instanceof A) {...} else {...}), а также вы не можете поменять свою активность на например класс контроллера или любое другое решение, которое вы придумаете.

Если вам трудно понять эту тему, я настоятельно рекомендую вам прочитать книгу Эффективная Java.

person Reinier    schedule 09.03.2015

arrow_upward
4
arrow_downward

В этом подходе нет неотъемлемого «преимущества», кроме того, что

  • это узнаваемая идиома. Использование интерфейсов — это распространенный способ взаимодействия двух классов в Java.
  • один и тот же код можно повторно использовать во многих разных Fragment и Activity.
  • он следует общим принципам модульности и абстракции, в которых Fragment «сообщает» Activity, что он достиг определенного состояния, а Activity определяет свое собственное поведение по отношению к этому состоянию.
person Y.S    schedule 09.03.2015
comment
Я думаю, что второй должен быть. Тот же fragment можно использовать из большего количества activitie (это можно сделать после getActivity(), но с последующими проверками и приведениями instanceof...) - person DNax; 09.03.2015
comment
@ZygoteInit Уже сделал!! Как вы дали этот ответ! Я сразу же проголосовал за это! Спасибо : ) !! - person KunYu Tsai; 19.03.2015

arrow_upward
1
arrow_downward

Я думаю, что большинство преимуществ подхода, основанного на интерфейсе, заключается в его хорошо известной и удобочитаемой модульности и достаточно высоком уровне абстракции с точки зрения разработки программного обеспечения.

Предположим, вы работаете в команде, и каждый товарищ по команде отвечает за один из этих компонентов, например, предполагается, что вы должны реализовать этот фрагмент, а я должен реализовать эту деятельность. Так как мы слишком далеко друг от друга, мы должны согласовать общий интерфейс в качестве стандарта между нами, а затем мы должны реализовать наши компоненты, соответствующие этому стандарту, в данном случае наш согласованный интерфейс. Также с точки зрения разработки программного обеспечения программная система на основе компонентов состоит из ряда компонентов, которые действуют независимо друг от друга, и их взаимодействие осуществляется только через стандартные общие интерфейсы, а материалы внутри каждого компонента прозрачны для других.

Поэтому в вашем случае Activity и Fragment следует рассматривать как два отдельных компонента, каждый из которых не знает подробностей о другом. И вот появляется интерфейс Java.

person frogatto    schedule 10.03.2015