Question

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

如果用户已经注册，则用户可以登录
用户可以发送消息
用户可以退出

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

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

Answer 1

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

就像有10件文书工作一样。你会为10张纸买多少组织者？你会把组织者放多少个橱柜？

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

Answer 2

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

让我们举个例子：

登录。
发送消息。
退出。

在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的派生，称为Model-View-Presenter。在MVP中，演示者承担了＆＃34;中间人＆＃34;的功能。（详情here）。让我们使用一个例子：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，Presenter）。当然，你可以将Presenter与View分开，但是，这是一个非常简单的应用程序，类分离就足够了。

如果你在组件之间有清晰的分离，就像在MVP中那样，它们可以很容易地为每个组件进行独立的仪器测试 - 只需模拟其他组件。我再次建议阅读： https://developer.android.com/topic/libraries/architecture/guide.html，有关于如何测试每个组件的整个部分。

Answer 3

模块化描述了将应用程序拆分为离散部分并定义用于管理这些部分之间通信的API。如果模块之间的所有通信都通过这些API进行，则模块被称为松散耦合。这带来了诸如（简要）......

等好处

模块内易于更改，因为一个模块内部的更改不会影响任何其他模块
分别开发，构建和测试每个模块的能力
...在这里加载更多

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

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

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

共同重用原则：包中的类可以一起重用。如果您重用了包中的某个类，则可以重复使用它们。
Common-Closure原则：包中的类应该针对相同类型的更改一起关闭。影响包的更改会影响该包中的所有类，而不会影响其他包。

测试树的组织应该反映主树的组织。如果主要包装得到很好的考虑，那么测试包也是如此。或者换句话说，如果你发现编写测试用例变得更加困难，因为依赖于看起来位于错误位置的类和包，那么这是一个明确的提示，你应该重新考虑你的包装方法。

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

Android模块和代码orginizing

3 个答案:

更新

MVC怎么样？