六大原则
- 单一职责：类的职责应该单一
- 开闭原则：对扩展开发，对修改关闭
- 里氏替换：若要扩展类功能，应该继承类实现，而不是直接修改原有类
- 依赖倒置：不同模块间通信，应该调用接口，而不是调用对象实体。程序要依赖于抽象接口，不要依赖于具体实现。
- 接口隔离：与多个模块通信，应该接口最小化。客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。
- 迪米特原则：一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象有尽可能少的了解
架构衍化
发展：单文件 -》 MVC -》 MVP -》 MVVM
理解
- 数据（Model）：数据以及对数据进行的操作（不依赖视图的操作）例如：Rxjava变换
- 视图（View）：不同模式有不同的定义（大概相当于 xml+activity+fragment）
- 逻辑（Controller）：view和model之间的通信与交互。多个model之间的逻辑处理。
单文件
优点：能够快速实现需求，视图操作和数据操作都很快捷
缺点：数据操作、逻辑控制、视图控制都混在一起，随着需求越发复杂，整个文件越来越难以修改，越来越容易出错，难以理解。
适用：演示用的示例程序。
思考：文件中有多个数据类声明可以移除出去，减小文件体积，比如 状态类、枚举类等。
MVC
此时
-
数据（Model）：数据实体bean、枚举类、状态类等
-
视图（View）：activity/fragment中的视图操作 、xml
-
逻辑（Controller）：activity/fragment 中对model 和view 的操作
优点：抽离了model层
缺点：controller 的权利太大，什么都能做。view是activity创建的，model也是activity创建的，权利太大。因此在迭代开发过程中，activity很容易就乱了。另外，逻辑控制逻辑也会在activity中，随着逻辑复杂起来，activity会越来越大。
适用：简单、逻辑改动小的项目
思考：activity权利太大，那就削弱它。逻辑控制的代码占大部分，是否能够抽离出去，减小activity 的复杂度。但是又要考虑分离出去的逻辑层的权利如何控制？答案是通过接口控制，只允许逻辑代理类通过我给你的接口操作视图和数据。那么就出现了MVP架构。
MVP
此时
- 数据（Model）：IModel接口、数据实体bean、枚举类、状态类等
- 视图（View）：activity/fragment 、 IView接口、 xml
- 逻辑（Controller）：IPresenter接口、Presenter文件
优点：把视图、数据、逻辑操作都分离出来了，满足了单一职责原则，逻辑变得非常清晰。
缺点：增加了多个接口，文件和方法增多了，导致一个变动需要修改多个文件。不利于需求变动。
适用：复杂、核心、多逻辑变更少视图变更的大型项目。
思考：考虑到 Presenter 中存在大量的 set、get 类似方法用于更新数据和视图，那么能不能让这两者同步起来呢？只需要更新model，让view自己同步刷新。由此，引入了 MVVM。
MVVM
必要条件：引入 DataBinding
备注：DataBinding 与 ViewBinding 是不同的，要区分开。
此时
-
数据（Model）：Viewmodel 、数据实体bean、枚举类、状态类等
-
视图（View）：activity/fragment 、 xml
-
逻辑（Controller）：Model 、BindingAdapter文件等
优点：在 MVP 的基础上增加了数据绑定，减少了代码量
缺点：XML 布局中包含了代码
适用：核心、复杂、多变更的大型项目