Android模块和代码的组织

Question

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

1. 如果用户已经注册，用户可以登录。
2. 用户可以发送消息
3. 用户可以签出

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

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

Answer 1

你需要做三件相当简单的事情。它们每个都需要一个视图，有两个实体(用户和消息)，并且会有一些帮助类或更多的帮助类。这听起来像是10级以下的课程。

就像有10份文件一样。你会花10张纸买多少个组织者？你会把组织者放在多少个橱柜里？

就这样。接吻。只要项目很小，将所有东西都放在一个包中是最实用的。编写单元测试可以帮助您限制依赖项，以便在代码增长时可以将代码拆分为包甚至模块。把所有的东西都放在一个地方并不能阻止你进行测试，也不会阻止你做任何其他的事情。它很好，只是当项目增长时变得糟糕，因为没有可见的结构。当这种情况发生时，您将更清楚地知道如何进行拆分。

Answer 2

模块可能意味着几件事，这取决于上下文。通常，像这样的术语非常模糊。在Java/Kotlin中，可以是类，也可以是包。就Android而言，它可以是应用程序的一个概念上(或有趣的)独立组件。此外，这些组件通常驻留在单独的文件(类)和包中，因此存在语义重叠。

以你的例子为例：

1. 登录。
2. 发个口信。
3. 签个名。

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

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

在这里你有：

• ui -负责UI逻辑的模块/组件(同时也包括包)。
• SplashActivity -负责管理与登录/注册有关的逻辑。从概念上讲，我们也可以将其称为模块。物理上是类/文件。
• data -只负责数据操作的大模块/组件。再一次，在身体上，一个包裹。
• db -专门负责数据库逻辑的子模块。

诸若此类。我想要推动的一点是:模块将更多地充当抽象。

关于单元测试。模块化设计将始终使应用程序更易于测试。在本例中，所有UI逻辑都与数据逻辑分离，因此可以非常容易地对所有数据进行模拟。只要所有细节都隐藏在合适的界面后面，Activity就不在乎数据从哪里提取。这是一个有点宽泛的问题，所以我向您推荐Android的应用程序体系结构指南，它正是关于模块化设计的：https://developer.android.com/topic/libraries/architecture/guide.html。

更新

MVC呢？

Android使用MVC的派生，称为模型-视图演示者。在MVP中，演示者假定“中间人”(details 这里)的功能。让我们举一个例子：https://github.com/googlesamples/android-architecture/tree/todo-mvp。这款谷歌简单易用的应用说明了MVP的设计。其组织方式如下：

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

正如您所看到的，这个布局非常类似于我前面所介绍的。数据(模型)逻辑保存在单独的包和UI逻辑一起(视图，演示者)。当然，您可以将演示者与View分离开来，但是，这是一个非常简单的应用程序，而且类分离就足够了。

如果组件之间有清晰的分离，就像在MVP中一样，那么很容易独立地对每个组件进行测试--只需模拟其他组件。同样，我建议阅读：https://developer.android.com/topic/libraries/architecture/guide.html，有一个关于如何测试每个组件的完整章节。

Answer 3

模块化描述了将应用程序分割成离散部分，并定义控制这些部分之间通信的API。如果模块之间的所有通信都通过这些API，那么这些模块被称为松散耦合。这带来了诸如(简略)…之类的好处。

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

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

• 逻辑分离
• 物理分离
• 某种模块化系统，如OSGI或Jigsaw项目在Java 9中产生的任何东西

这就是背景。在Android应用程序的上下文中(您的问题有标记)，我建议一个模块就足够了，您应该使用打包来定义模块内部的逻辑分离。您会发现很多关于逐功能包和逐层包其他地方的描述，虽然阅读这些常见方法当然是有意义的，但它们都有两个基本原则支持：

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

测试树的组织应该反映出主树的组织结构。如果主包被很好地考虑，那么测试包也会被考虑在内。或者换一种说法，如果您发现编写测试用例变得更加困难，那么您应该重新考虑您的打包方法。

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