在 Java 中使用内部类拆分大类

Question

我正在开发一个 Android 项目。我搜索了高低，但我无法找到一个好的策略来拆分和打包我的代码。

我的问题是我有使用主类变量的内部类，我不知道如何将它们解耦。

我曾尝试创建辅助类，但要么我通过构造函数传递了很多变量，要么我暴露了我的主类，我都不想这样做。

我想将每个类的最大代码行数保持在 150 行。目前是 278 行。我正在寻找解耦这些的想法，特别是如何重组类以保留抽象 (private变量）。 Java 的最佳做法是什么？

例如，here 是我的主要课程之一，MainActivity，约 300 行。

Answer 1

取出你的内部类，将 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"));

Answer 2

编辑：

添加MainActivivty 的实际代码后，我建议如下：

1. 遵循 MVC/MVP 架构模式。您可以找到我在最后编写的模板的链接，但还有更多模板 - 只需选择您喜欢的一个即可。一旦你了解了如何获取 MainActivity 之外的所有 UI 相关代码，addButtons() 方法以及 CategoriesListener 类将消失。
2. AllPostsFetchAsyncTask 确实没有必要成为内部类。将其作为活动之外的常规课程实施。为了将这个类的数据传回MainActivity，只需定义一个你的MainActivity将实现的监听器接口，并将MainActivity.this传递给构造函数——当这个任务完成时，它将调用一个回调方法MainActivity，反过来，它将处理与Adapter 的数据绑定。事实上，你在这里采用了一种非常糟糕的做法——通过让AllPostsFetchAsyncTask 了解MainActivity 的实现细节，你在两者之间造成了不必要的耦合，从而违反了 OOP 的封装、单一职责和开放封闭原则。

只需执行上述两个步骤，您就可以使这个特定的MainActivity 方式少于 150 行代码。

也就是说，您将 Activity 保持 150 行长的意图过于严格。这归结为一个事实，如果你的Activity 或Fragment 不是微不足道的，那么一旦你实现了onCreate()、onPause()、onResume()、onPrepareOptionsMenu()、onBackStackChanged() 和其他标准生命周期方法，那么甚至在您添加自定义控制器的逻辑之前，您可能会有超过 150 行代码。

现在，我完全讨厌内部类，并试图不惜一切代价避免它们。以下清单可以作为指导，但无论如何都不完整：

• 切勿在控制器/演示器中操作 UI 元素（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

希望对你有帮助

Answer 3

如果内部类只访问字段，则引入一个新的 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，并且可以避免循环依赖。

Answer 4

这是对部分问题的回答。如问题所述

我曾尝试创建辅助类，但是我通过构造函数传递了很多变量

这与Telescoping constructor 非常相似。所以，为了解决这个问题，我个人会使用类似于 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 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;
     }     

   }
}

Answer 5

首先，基于你的Activity的实现，你错过了一些关于Activity的重要事情。

1.仅为 AsyncTasks 使用静态内部类或独立类：参见 Background task, progress dialog, orientation change - is there any 100% working solution?

重要的是：

第 2 步：让 AsyncTask 通过数据成员持有 Activity，通过构造函数和 setter 进行设置。

第 5 步：在 onCreate() 中，如果 getLastNonConfigurationInstance() 不为 null，则将其强制转换为 AsyncTask 类并调用 setter 以将新活动与任务相关联。

您会注意到，您必须根据 Android 的生命周期方法注册和注销您的组件。了解这一点很重要，始终遵循 Android 生命周期！

记住这一点将始终引导您找到有关解耦 Android 方式的正确答案。

2。在需要时使用数据保存类。

这里并不真正属于 Activity：

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

当您的 Activity 被销毁时，例如在配置更改期间，您的所有数据都消失了，您需要重新加载所有内容。

可以通过多种不同方式访问和存储您的数据：http://developer.android.com/guide/faq/framework.html#3

在您的情况下，这可能适用：

• 公共静态字段/方法

  使数据可跨活动/服务访问的另一种方法是使用公共静态字段和/或方法。 您可以从您的任何其他类访问这些静态字段 应用。共享一个对象，创建你的活动 object 设置一个静态字段来指向这个对象和任何其他 想要使用这个对象的活动只是访问这个静态 字段。

还可以考虑将您的数据存储在数据库中或通过其他方式，这样即使您的应用程序被销毁，您的数据也不会消失。

3.与您的 Activity 的通信可以这样完成：http://developer.android.com/guide/components/fragments.html#CommunicatingWithActivity

以相同的方式将它用于您的视图和视图侦听器。让一个组件管理您的视图（就像 Fragment 一样），将其注册到您的 Activity，使用它，在不需要或生命周期需要时取消注册。

正如1.中所说，Android 生命周期是一切的关键。

4.依赖注入 是一个非常重要的主题，您可以使用框架（如 Dagger 2 或 RoboGuice），也可以按照自己的方式进行。确保您的 Injector 知道依赖关系（例如哪些 Button 需要哪些 ClickListeners 和 Information 或您的 Adapter 需要哪些数据）并将它们绑定在一起。当始终考虑生命周期时，您会看到需要哪些接口和哪些方法以及何时调用它们。

5.不用担心代码行数。如果您的设计是一致且有意义的，那么即使有 500 行，您也不会遇到可读性问题。顺便提一句。当正确地记录你的代码时，它很容易超过 150 行代码。所以，再次担心这一点。

如果您对实施细节有任何具体问题，请提出具体问题，否则您会得到一个臃肿的答案。