Разделение больших классов на внутренние классы в Java

Изменить:

После добавления фактического кода для MainActivivty я бы предложил следующее:

1. Следуйте архитектурному шаблону MVC/MVP. Вы можете найти ссылку на шаблон, который я написал в конце, но шаблонов гораздо больше - просто выберите тот, который вам нравится. Как только вы поймете, как получить весь код, связанный с пользовательским интерфейсом, за пределами MainActivity, метод addButtons() исчезнет, ​​как и класс CategoriesListener.
2. На самом деле нет необходимости, чтобы AllPostsFetchAsyncTask был внутренним классом. Реализуйте его как обычный класс вне активности. Чтобы передать данные из этого класса обратно в MainActivity, просто определите интерфейс прослушивателя, который будет реализовывать ваш MainActivity, и передайте MainActivity.this конструктору — когда эта задача будет завершена, он вызовет метод обратного вызова для MainActivity, который в свою очередь, будет обрабатывать привязку данных к Adapter. На самом деле, вы применяете здесь очень плохую практику — сообщая AllPostsFetchAsyncTask о деталях реализации MainActivity, вы создаете ненужную связь между ними, тем самым нарушая принципы инкапсуляции, единой ответственности и открытого и закрытого ООП.

Просто выполнив два описанных выше шага, вы сделаете этот конкретный MainActivity способ короче, чем 150 строк кода.

Сказал, что ваше намерение сохранить активность в 150 строк слишком ограничительно. Это сводится к тому, что если ваши Activity или Fragment нетривиальны, то после того, как вы реализуете onCreate(), onPause(), onResume(), onPrepareOptionsMenu(), onBackStackChanged() и другие стандартные методы жизненного цикла, у вас, вероятно, будет более 150 строк кода еще до того, как вы добавьте логику вашего пользовательского контроллера.

Теперь я полностью ненавижу внутренние классы и стараюсь избегать их любой ценой. Следующий контрольный список может служить руководством, но он никоим образом не является полным:

• Никогда не манипулируйте элементами пользовательского интерфейса в контроллерах/презентаторах (Activities, Fragments и Adapters) — инкапсулируйте эти манипуляции в отдельные классы. Эти классы являются представлениями MVC/MVP (в отличие от Android View). и я кладу их в пакеты views или mvcviews. Мои Activities и Fragments обычно не имеют вызовов findViewById() в исходном коде.
• Поместите все Adapters в отдельный пакет (даже если они длиной 30 строк). Я называю этот пакет controllers.adapters или controllers.listadapters
• Если вам когда-либо понадобится передать набор связанных данных в ваше приложение, определите POJO (также известный как объект значения) и использовать его для инкапсуляции этих данных. Обычно у меня есть пакет с именем pojos, даже если он содержит только один класс.

• Определите абстрактные классы AbstractActivity и AbstractFragment и поместите туда любую удобную логику, которая используется вашими контроллерами. Например: у меня всегда есть следующий метод (или аналогичный) в моих AbstractActivity и AbstractFragment:

  public void replaceFragment(Class <? extends Fragment> claz, boolean addToBackStack, Bundle args) { 
      // Code to replace the currently shown fragment with another one 
  }
  

• Проверьте, есть ли какие-либо сторонние библиотеки, которые могут быть полезны в контексте вашего приложения, и используйте их.

Моя упаковка обычно следует такой схеме:

Я знаю, что вы писали, что уже видели некоторые обсуждения MVC, но я все же рекомендую вам попробовать реализацию, которую я предлагаю в этом шаблоне/учебном проекте: https://github.com/techyourchance/android_mvc_template

Надеюсь это поможет

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

<сильный>1. Используйте только статические внутренние классы или автономные классы для AsyncTasks: см. any-100-working/3821998#3821998">Фоновая задача, диалоговое окно прогресса, изменение ориентации - есть ли какое-либо 100% рабочее решение?

Важно вот что:

Шаг 2. Пусть AsyncTask удерживает действие с помощью члена данных, устанавливаемого с помощью конструктора и установщика.

Шаг 5. В onCreate(), если getLastNonConfigurationInstance() не равен null, приведите его к классу AsyncTask и вызовите установщик, чтобы связать новую активность с задачей.

Вы заметите, что вам придется регистрировать и отменять регистрацию ваших компонентов на основе методов жизненного цикла Android. Это важно знать, всегда следите за жизненным циклом Android!

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

<сильный>2. При необходимости используйте классы хранения данных.

Здесь это не относится к Activity:

// Stores the fetched dataMap
ArrayList<HashMap<String, String>> arrayList;

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

Доступ к данным и их хранение можно осуществлять разными способами: http://developer.android.com/guide/faq/framework.html#3

В вашем случае это может быть применимо:

• Общедоступное статическое поле/метод

  Альтернативный способ сделать данные доступными между действиями/службами — использовать общедоступные статические поля и/или методы. Вы можете получить доступ к этим статическим полям из любого другого класса вашего приложения. Чтобы поделиться объектом, действие, которое создает ваш объект, устанавливает статическое поле, чтобы оно указывало на этот объект, и любое другое действие, которое хочет использовать этот объект, просто получает доступ к этому статическому полю.

Также подумайте о хранении ваших данных в БД или другими способами, чтобы даже после уничтожения вашего приложения ваши данные не исчезли.

<сильный>3. Связь с вашей активностью может осуществляться следующим образом: http://developer.android.com/guide/components/fragments.html#CommunicatingWithActivity

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

Как сказано в 1., жизненный цикл Android — это ключ ко всему.

<сильный>4. Внедрение зависимостей — очень важная тема, и вы можете либо использовать для этого фреймворк (например, Dagger 2 или RoboGuice), либо сделать это по-своему. Убедитесь, что ваш инжектор знает зависимости (например, каким кнопкам нужны какие ClickListeners и информация или какие данные нужны вашему адаптеру) и свяжите их вместе. Всегда рассматривая жизненный цикл, вы увидите, какие интерфейсы и какие методы вам нужны и когда их вызывать.

<сильный>5. Не беспокойтесь о количестве строк кода. Если ваш дизайн последователен и имеет смысл, у вас не будет проблем с читабельностью даже при 500 строках. Кстати. при правильном документировании вашего кода он легко превышает 150 строк кода. Итак, снова беспокоиться об этом.

Если у вас есть какие-либо конкретные вопросы о деталях реализации, задайте конкретный вопрос, иначе вы получите раздутый ответ.

Это ответ на часть проблемы. Как указано в вопросе

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

Это нечто очень похожее на телескопический конструктор. Итак, для решения этой проблемы я бы лично использовал что-то похожее на Builder Pattern.

class A {
  public class B {
     public B(int x, int y, int z, int m, int n, int o){

     }
  }
}

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

class A {
   public class B{
     int a, int b, int c, int m, int n, int p = 0;
     public B(){
     }
     public B setA(int x){
       a = x;
       return this;
     }     
     public B setB(int x){
       b = x;
       return this;
     }
     ... and similar methods for other properties.     
   }
}

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

class A {
   public class B{
     int a, int b, int c, int m, int n, int p = 0; // key for int a == "a" and for b is "b" and so on... this is our assumption.
     public B(){
     }
     public B setProperty(String key, int value){
       if(key.equals("a")){
           a = value;
       }else if(key.equals("b")){
           b = value;
       } ... and so on for other properties.
       return this;
     }     

   }
}

Если внутренние классы имеют доступ только к полям, тогда введите новый класс Container для всех соответствующих полей вашего класса MainActivity (конечно, вы также можете сделать два или три крошечных контейнера вместо одного большого).

Затем ваш пример может быть изменен на это:

/** new container class */
class FooBar {
    public Foo foo;
    public Bar bar;
}

/** nice, easy and SHORT! */
class MainActivity {

    private FooBar fooBar;

    public MainActivity() {
        new Ping(fooBar);
        new Pong(fooBar).someMethod();
    }
}

/** successfully converted from inner class to class */
class Ping {

    public Ping(FooBar fooBar) {
        fooBar.foo = new Foo(); // Ping modifies Foo
    }
}

/** successfully converted from inner class to class */
class Pong {

    private Bob bob;
    private FooBar fooBar;

    public Pong (FooBar fooBar) {
        this.fooBar = fooBar;
        fooBar.bar = new Bar(); // Pong modifies bar
        bob = new Bob();
    }

    public void someMethod () {
        fooBar.bar.setSomethingTo(Bob.getSomething()); // Pong modifies bar of Main class
        fooBar.foo = new Foo(fooBar.bar); // Pong assignes something to bar
    }
}

Я использовал эти заглушки классов для компиляции кода:

class Foo {
    public Foo() {}
    public Foo(Bar bar) {}
}
class Bar {
    public void setSomethingTo(String something) {}
}
class Bob {
    static String getSomething() {return "Something";}
}

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

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

MainActivity mainActivity;
DownloadJSON(MainActivity mainActivity) {
        super();
        mProgressDialog = new ProgressDialog(MainActivity.this);
        mProgressDialog.setCancelable(false);
        this.mainActivity=mainActivity;
    }

Сделайте переменные в mainActivity общедоступными, и вы сможете получить к ним доступ следующим образом:

          // Extract the metadata
         mainActivity.pageCount =Integer.parseInt(metaData.get("PAGE_COUNT"));