使用Java中的Inner类拆分大类

ps9*_*s95 14 java android packaging inner-classes object-oriented-analysis

我正在开发一个Android项目.我已经搜索过高低,但我无法找到一个好的策略来拆分和打包我的代码.

我的问题是我有内部类使用主类变量,我无法弄清楚如何解耦它们.

我试图创建辅助类,但是我要么通过构造函数传递很多变量,要么暴露我的主类,我也不想这样做.

我想将每个类的最大代码行保持为150.目前,它是278.我正在寻找解耦这些的想法,特别是如何重构类以保留抽象(private变量).这方面的Java最佳做法是什么?

举个例子,是我的主要课程之一MainActivity,约30​​0行.

Vas*_*liy 4

编辑:

添加实际代码后MainActivivty,我建议如下:

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

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

话虽如此,您将活动保持 150 行长的意图过于严格。这归结为这样一个事实:如果您的ActivityFragment不是微不足道的,那么一旦您实现onCreate()onPause()onResume()onPrepareOptionsMenu()onBackStackChanged()其他标准生命周期方法,那么即使在添加自定义控制器的逻辑之前,您也可能拥有超过 150 行代码。

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

  • Activities切勿在控制器/演示器( 、Fragments和)中操作 UI 元素Adapters- 将这些操作封装在单独的类中。这些类是 MVC/MVP 视图(与 Android View相对),我将它们放入viewsmvcviews包中。我的Activities源代码中的调用Fragments往往为零。findViewById()
  • 将所有内容Adapters放入单独的包中(即使它们有 30 行长)。我称这个包controllers.adapterscontrollers.listadapters
  • 如果您需要在应用程序中传递一组相关数据 - 定义一个POJO(也称为值对象)并使用它来封装这些数据。我通常有一个名为 的包pojos,即使它只包含一个类。
  • 定义抽象类AbstractActivityAbstractFragment放置控制器使用的任何便利逻辑。例如:我的AbstractActivityand中总是有以下方法(或类似的方法) AbstractFragment

    public void replaceFragment(Class <? extends Fragment> claz, boolean addToBackStack, Bundle args) { 
        // Code to replace the currently shown fragment with another one 
    }
    
    Run Code Online (Sandbox Code Playgroud)
  • 检查是否有任何第三方库可能在您的应用程序上下文中有用并使用它们。

我的包装通常遵循以下模式:

在此输入图像描述

我知道您写道您已经看过一些关于 MVC 的讨论,但我仍然鼓励您尝试我在此模板/教程项目中建议的实现:https://github.com/techyourchance/android_mvc_template

希望这可以帮助