Блог

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

Я делаю это не потому, что мне нужен доступ ко всему activity, а скорее потому, что мне нужен доступ к:

1. Члены (либо данные, либо методы) activity
2. Элементы данных, которые еще не инициализированы на момент вызова этих конструкторов.

Это работает, но у меня постоянное ощущение, что я делаю что-то в корне неправильное с точки зрения надлежащего ООД.

Особенно в отношении пункта # 1:

1. Члены, которые настолько «приватны» для Activity, становятся, по сути, беспорядочным пулом глобальных переменных.
2. Кроме того, те другие классы, которые были созданы с целью модульности, теперь зависят от знания класса activity, что делает их на самом деле не пригодными для повторного использования вне этого приложения…

По этим причинам я стараюсь по возможности избегать передачи activity в качестве параметра конструкторам, но в среде разработки Android мне это сделать сложнее по причинам, которые я еще не до конца понимаю.

Мои вопросы:

1. Существуют ли рекомендуемые «эмпирические правила», которые могут помочь избежать этой ловушки с использованием «ярлыка» путем передачи activity в качестве параметра?
2. Существуют ли случаи, в которых передача activity в качестве параметра концептуально оправдана?

Вообще говоря, вам следует избегать сохранения ссылок на activities. Если вам действительно нужно, сохраните слабую ссылку на вашу activity. Это делается для того, чтобы избежать утечек памяти.

Как вы сказали, передавая ссылку на activity, вы вводите зависимость между другим объектом и вашим классом activity. Приведите несколько примеров кода, чтобы мы могли привести пример того, как его реорганизовать.

Я обнаружил, что лучше всего хранить значения, которые потребуются нескольким классам, в отдельном классе Util. Таким образом, вам не нужно передавать основную Activity другим классам.

Альтернативой этому является передача требуемых значений, которые основное Activity имеет в качестве параметров, другим классам по мере необходимости.

Что касается вашего 2-го вопроса, я не могу придумать ни одной причины, по которой вам пришлось бы передавать свою основную activity, а затем вызывать для нее методы.