Java Android模块和代码组织

假设有人说你的应用程序中必须有这些模块

如果用户已经注册，则可以提供用户登录

用户可以发送消息

用户可以注销

他们所说的模块可以说你的应用程序必须具备这些功能，我理解模块是你应用程序的一个组件，你可以独立构建、测试或调试。模块包含应用程序的源代码和资源

我的问题是，如果他们这样说，那么我如何以专业的方式组织我的代码？我是否必须为每项功能制作单独的软件包？或者我必须为每个功能创建单独的模块，我对代码的组织感到困惑。

模块可能意味着一些事情，具体取决于上下文。通常，像这样的术语非常模糊。在Java/Kotlin中，它可以是类或包。就Android而言，它可以是应用程序中概念上（或功能上）独立的组件。此外，这些组件通常位于单独的文件（类）和包中，因此存在语义重叠

让我们以你为例：

登录

发送消息

注销

在Android上，您可以这样建模：

app
 ˪ ui
    ˪ SplashActivity
          ˪ SignInFragment
          ˪ SignUpFragment
 ˪ data
    ˪ db
       ˪ DatabaseManager
       ˪ models
           [model classes]
    ˪ api
       [classes responsible for network communication]

给你：

• ui

  -负责ui逻辑的模块/组件（同时还有包）

• SplashActivity

  -负责管理有关登录/注册的逻辑。从概念上讲，我们也可以将其称为一个模块。物理上是一个类/文件

• 数据

  -仅负责数据操作的大模块/组件。同样，在同一时间，物理上，一个包

• db

  -专门负责数据库逻辑的子模块

等等。我试图说明的一点是：模块通常充当抽象

关于单元测试。模块化设计总是使应用程序更易于测试。在上面的示例中，所有UI逻辑都与数据逻辑分离，因此可以非常容易地模拟所有数据<代码>活动不关心从何处提取数据，只要所有细节都隐藏在合适的界面后面。 这是一个有点宽泛的问题，所以我向您推荐Android的应用程序架构指南，它正是关于模块化设计的：

更新 MVC呢？ Android使用MVC的派生，称为模型视图演示器。在MVP中，演示者承担“中间人”（细节）的功能。让我们使用一个例子：。这是谷歌简单的待办应用程序，展示了MVP设计。它的组织如下：

todoapp
 ˪ data
     ˪ source
     ˪ Task.java (model)
 [...]
 ˪ tasks
    ˪ TasksActivity.java
    ˪ TasksFragment.java
    ˪ TasksPresenter.java
    [...]

如您所见，此布局与我前面介绍的非常相似。数据（模型）逻辑保存在单独的包和UI逻辑中（视图、演示者）。当然，您可以进一步将Presenter和View分开，但是，这是一个非常简单的应用程序，类分离就足够了

如果组件之间有清晰的分离，就像在MVP中一样，很容易独立地为每个组件测试仪器——只需模拟其他组件即可。我再次建议阅读：

---

模块化描述了如何将一个应用程序拆分为几个独立的部分，并定义了控制这些部分之间通信的API。如果模块之间的所有通信都通过这些API进行，则这些模块称为松耦合。这带来了一些好处，例如（简单地说）

• 易于在模块内进行更改，因为一个模块内部的更改不会影响任何其他模块
• 独立开发、构建和测试每个模块的能力
• …这里装载更多

模块化可能涉及以下部分或全部：

• 逻辑分离
• 物理分离
• 某种模块化系统，如OSGI或Jigsaw在Java9中生成的任何项目

这就是背景。在Android应用程序（您的问题标记了该应用程序）的上下文中，我建议一个模块就足够了，您应该使用打包来定义该模块内的逻辑分离。你会发现大量关于功能包和层次包的描述，虽然阅读这些常用方法肯定是有意义的，但它们都有两个基本原则作为基础：

• 通用重用原则：包中的类一起重用。如果重用包中的一个类，那么就重用了所有类
• 通用的关闭原则：包中的类应该针对相同类型的更改关闭在一起。影响包的更改会影响该包中的所有类，而不会影响其他包

测试树的组织应该反映主树的组织。如果主要的软件包考虑得很好，那么测试软件包也会考虑得很好。或者换一种方式说，如果您发现编写测试用例由于依赖似乎位于错误位置的类和包而变得更加困难，那么这是一个明确的提示，您应该重新考虑您的打包方法

---

作为一个起点，你可以看看现有的开源Android应用程序，看看是否有共同的模式出现。你也可以看看一个相关的SO问题。但最终，你将最了解你的应用程序的细节，因此，虽然众所周知/广泛使用的结构是一个很好的起点，但随着你自己的应用程序的发展，你可能不得不改变它，在这个阶段，重构工具和测试覆盖率将非常有用。

你需要做三件相当简单的事情。它们中的每一个都需要一个视图，有两个实体（用户和消息），并且会有一些或更多的助手类。这听起来好像不到10节课

就像有10份文件一样。你会用10张纸买多少个组织者？如何