文章目录
- 架构设计
- 为什么要进行技术框架的设计
- 六大设计原则
- 一、单一职责原则
- 二、开闭原则
- 三、依赖倒置原则
- 四、接口分离原则
- 五、迪米特法则（又称最小知道原则）
- 六、里氏替换原则
- 案例诠释
- 安卓主流开发技术框架
- MVC模式
- MVP模式
- MVVM
- MVP模式详解
架构设计
为什么要进行技术框架的设计
- 模块化功能：使得程序模块化，即内部高聚合，模块之间低耦合
- 提高开发效率：开发人员只需要专注于一点（视图显示、业务逻辑、数据处理）
- 提高测试效率：后期测试时可以迅速根据报错反馈，定位到问题出现的位置。
六大设计原则
六大设计原则是设计模式的理论，设计模式是设计原则的实践。
一、单一职责原则
一个类只负责一个职责，术语叫仅有一个引起变化的原因。一个类应该是一组相关性很高的函数及数据的封装。
二、开闭原则
一个软件实体应该对扩展开放，对修改关闭。
提倡一个类一旦开发完成，后序增加新的功能，不应该通过修改这个类实现，而是通过继承或者接口实现增加新的类。
三、依赖倒置原则
抽象不应该依赖于细节，细节应该依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
也就是说两个模块之间的通信应该通过接口来实现。
四、接口分离原则
使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。即让调用者依赖的接口尽可能小，接口分离类似于单一职责原则。
五、迪米特法则（又称最小知道原则）
一个软件实体应该尽可能地减少与其他实体发生相互作用。或者说一个类，对自己需要调用的类知道得最少，类的内部应该与被调用者无关，也称迪米特隔离。
例如使用一个Thread类下边的run方法，按照迪米特原则，可以把run单独抽离出来，构建一个Runnable接口供userClass使用，这样调用者userClass与Thread之间的交互是最少的。
六、里氏替换原则
所有引用基类（父类）的地方，必须能够透明的使用其子类的对象。即一个软件系统中，把所有用到某个类的地方都替换为其子类，系统应该仍然可以正常工作。这个原则依赖面向对象的继承特性和多态特性。
案例诠释
- 按照
单一职责原则构建一个类或者接口 - 基于
开闭原则继承类或者实现接口，来构建新类。 - 基于
里式替换原则，所有使用父类的地方可以使用子类来替换。 - 与其他类之间交互时，基于
依赖倒置原则，使用接口通信。 - 接口设计时，基于
接口隔离原则，应该设计多个专门实现某种功能的接口 - 基于
迪米特原则，老师类要实现对同学的点名，应该通过一个用来跟同学交互的班长，分层次实现。
安卓主流开发技术框架
MVC模式
角色说明：
- Model：模型层，数据模型及其业务逻辑，是针对业务模型建立的数据结构，Model与View无关，而与业务有关。
数据的获取以及对数据进行的不依赖视图的操作 - View：视图层，用于与用户实现交互的页面，通常实现数据的输入和输出功能。
- Controller：控制层，用于连接Model层和View层，完成Model层和View层的交互。还可以处理页面业务逻辑，它接收并处理来自用户的请求，并将Model返回给用户。
模式说明：
存在的问题：
Activity责任不明，十分臃肿，Activity除了承担View层的部分职责（加载应用布局，监听并反馈用户操作），还要承担Controller层的功能（业务逻辑处理）。
随着界面的增多与逻辑复杂度的提高，Activity类的代码量不断增加，越加臃肿，使得项目调试和管理困难
MVP模式
为了解决MVC模式存在的问题，分离Activity中的View层和Controller层的职责，从而对Activity代码量进行优化和瘦身。
角色说明：
- Model 模型层：只负责存储数据，与View呈现无关，也与UI处理逻辑无关，发生更新也不用主动通知View
- View 视图层：人机交互接口，一般为展示给用户的界面，通过Activity实现。
- Presenter 表示层：负责连接V层和M层，完成交互，负责业务逻辑处理。
模式说明：View层接收用户的输入，View层与Model层交互必须经过Presenter层。
相对于MVC，MVP模式把原来的UI逻辑抽象为View接口，把原来的业务逻辑抽象为Presenter接口，Model还是原来的Model
在MVP模式中上下层之间的交互是双向的，View层和Model层之间被Presenter层完全隔绝。
对比MVC模式，它的优点在于：
- 耦合度更低，通过Presenter实现数据和视图之间的交互，完全隔离了View层与Mode层，二者互不干涉。
- Activity代码变得更加简洁：简化了Activity的职责，仅负责UI相关操作，其余复杂的逻辑代码提取到了Presenter层中进行处理。
MVVM
为了更加分离M、V层，更加释放Activity的压力，于是出现了MVVM（其中最后的VM表示viewmodel）
● M（Model，模型层 ）
● V（View，视图层）
● VM（ViewModel，V与M连接的桥梁，也可以看作为控制器）
MVVM基本与MVP模式完全一致，只是将表示层Presenter改名为ViewModel。
模式说明：
MVVM比较特别的地方在于采用了双向绑定（data binding）：view的变动，自动反映在ViewModel，反之亦然。
- ViewModel，View之间的交互通过Data Binding完成
- Data Binding可实现双向交互。
MVP模式详解
核心思想是原来UI逻辑抽象为View接口，把原来的业务逻辑抽离为Presenter接口，并且由具体的实现类来完成。具体实现思路如下：
- 把Activity中的UI逻辑抽象为View即可，由具体的类完成
- 把Activity中的业务逻辑抽象为Presenter接口，由具体的实现类来完成。
- Model类还是原来MVC模式中的Model层。
MVP模式的UML图如下：
通过UML图可以看出使用MVP模式的步骤如下：
- 设置view层：创建IView接口，放置所有视图逻辑的接口。其实现类是当前的Activity或者Fragment。
- 设置presenter层：创建IPresenter接口，放置所有业务逻辑的接口，创建它的实现类PresenterComl。
- 设置model层：放置业务逻辑，数据存储。model并不是必须有，但必须有presenter和view。
- 在activity里包含了一个IPreseter接口，而PresenterComl实现类包含一个ivew并依赖model层，
activity里只保留对Ipresenter接口的调用，其他工作全部留到PresenterCompl实现类中实现。
