Шаблон команды для передачи методов деятельности приложения?

Question

Прочитав статью Avoiding memory leaks от @RomainGuy, я понял, что мое текущее приложение для Android связано с ошибкой передачи основной деятельности приложения. Поэтому всякий раз, когда я, могу ли я просто заменить этот параметр активности на Activity.getApplicationContext().

Но в моем приложении есть определенные классы, которым все еще нужно запускать методы, которые могут быть только членами основной деятельности приложений.

Таким образом, я думал о возможном использовании Command Pattern, чтобы обойти это ограничение.

Проблема заключается в том, что, если мы посмотрим на этот пример:

public class SomeCommandExecuableOnlyByActivity implements Command 
{ 
    public void execute(Object data) 
    { 
     doIt(((MyActivity)data).getWindow()); 
    }  
} 

Я бегу снова в тупик необходимости проход вокруг деятельности (на этот раз под видом Object данные).

Как я могу выбраться из этой «курицы & яйцо»?

Есть ли лучший способ подойти к этой проблеме?

Answer 1

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

Следует ли использовать шаблон команды здесь, я не могу сказать, но то, что я обычно делал, это определить те методы, которые требуют совместного доступа, переместить их в отдельный класс и затем либо сохранить отдельный экземпляр этого класса в все действия, требующие этой функции, или если вам нужно обмениваться экземпляром состояния, создать его в глобальном контексте приложения и предоставить ему глобальный путь доступа (нежелательно, но без инфраструктуры DI, такой как RoboGuice, очень сложно реализовать DI на Android, поскольку конструкторы оказываются недействительными.)

На мой взгляд, в хорошо разработанном приложении для Android деятельность не имеет бизнес-логики и предоставляет только операции, которые изменяют состояние пользовательского интерфейса. Поток пользовательского интерфейса или любые другие вычисления будут оставлены для других классов. Model-View-Presenter pattern чрезвычайно помогает здесь, чтобы ваш код был структурирован под ответственность.

Не указывая на то, что вы точно пытаетесь достичь, трудно дать конкретный совет.