安卓基础巩固（六）：设计原则、安卓主流技术框架MVC/MVP/MVVM、设计模式
文章目录
- 架构设计
-
- 为什么要进行技术框架的设计
- 六大设计原则
-
- 一、单一职责原则
- 二、开闭原则
- 三、依赖倒置原则
- 四、接口分离原则
- 五、迪米特法则（又称最小知道原则）
- 六、里氏替换原则
- 案例诠释
- 安卓主流开发技术框架
-
- 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实现类中实现。
设计模式
构造型
单例模式
饿汉单例：初始化时直接创建一个静态的实例对象，这种方式天生就是线程安全的。
懒汉单例：实际需要使用时才创建，需要利用线程同步机制，有下边三种写法：
- 同步代码块：私有化构造函数，静态化实例成员，公开获取单例的静态方法，如果检测到实例未创建，使用synchronized构建同步代码块，因为是静态方法，所以使用类的字节码（类名.class）对象作为synchronized的锁对象。
class SingleInstance {
private SingleInstance() {
}
private static SingleInstance singleInstance;
public static SingleInstance getInstance() {
if (singleInstance == null) {
synchronized (SingleInstance.class) {
if (singleInstance == null) {
singleInstance = new SingleInstance();
}
}
}
return singleInstance;
}
}
- 使用同步方法，直接给获取单例的静态方法整体上锁。
class Single {
private Single(){
}
private static Single single;
public static synchronized Single GetInstance() {
if (single == null) {
single = new Single();
}
return single;
}
}
- 静态内部类 + final 内部成员
静态内部类的成员只在初次调用时被初始化，非常符合懒汉单例的方式。
class SingleByInner{
private SingleByInner() {
}
static class Inner {
private static final SingleByInner INSTANCE = new SingleByInner();
}
public static SingleByInner getInstance() {
return Inner.INSTANCE;
}
}
class SingleByInner{
private SingleByInner() {
}
static class Inner {
private static final SingleByInner INSTANCE = new SingleByInner();
}
public static SingleByInner getInstance() {
return Inner.INSTANCE;
}
}
工厂模式
简单工厂
- 简单工厂模式提出是为了实现在创建一个对象时，不向客户暴露内部细节，只提供一个创建对象的通用接口。（基于了迪米特法则/最小知道原则）
- 简单工厂把实例化的操作单独放到一个类中，这个类就成为简单工厂类，让简单工厂类来决定应用用哪个具体子类来实例化。
- 这样做能把客户类和具体子类的实现解耦，在业务中我们往往有多个客户类，如果客户类要知道所有子类的细节，一旦子类发生改变，那么所有的客户类都要修改。使用工厂模式则只需要修改工厂类，并在需要子类的客户类使用时修改接口参数即可。
工厂方法
定义了一个创建对象的接口，但由子类决定要实例化哪个类。工厂方法把实例化操作推迟到了子类- 在简单工厂中，创建对象的是工厂类，而在工厂方法中，是由工厂类的子类来创建对象。
生成器模式
封装一个对象的构造过程，并允许按步骤构造
行为型
监听者（观察者）模式
监听者用来监听自已感兴趣的事件，当收到自已感兴趣的事件时执行自定义的操作。
监听者模式在Android中有大量的运用，相信大家都不会感到陌生。在Android开发中，Button控件的点击事件就是监听者模式最常见的例子。
当Button被点击，执行了 OnClickListener.onClick。 Activity中给这个Button设置了自己实现的OnClickListener，并复写了onClick方法，就能执行自定义操作了。
中介者模式
用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地互相作用， 从而达到松耦合的目的。
由以下几个部分组成
- mediator 抽象中介者 - 用于协调各个同事之间的交互
- Concrete mediator 具体中介者角色 - 依赖于各个同事类
- Colleague 同事角色（要被封装的对象）
每个同事角色都知道中介者角色，但不与其他同事进行交互，而是通过中介者来调度。
- 优点是减少类间的依赖，把原来的一对多的依赖关系改变成了一对一的依赖。降低耦合。
- 缺点是中介者会变得很庞大，逻辑复杂。
代理模式
为其他对象提供一种代理以控制对这个对象的访问。也叫委托模式。
主要有三个角色：
- Subject抽象主题角色。 可以是抽象类或接口，是一个最普通的业务类型定义，无特殊要求。
- RealSubject具体主题角色。 也叫被委托角色、被代理角色。是具体业务的执行者。
- Proxy代理主题角色。 也叫委托类、代理类。负责对真实角色的应用，可以添加自定义的操作，例如预操作和善后处理。
优点：
- 职责清晰 - 真实角色只负责实现实际的业务逻辑，不用关系其他事务。代理可以完成更多工作。
- 高扩展性 - 只要实现了接口，具体主题角色的实现可以高度地改变，而不用改代理。
责任链模式
责任链模式是一种行为型设计模式，它用于将多个请求处理器对象连接成一条链，可以让请求沿着这条链不断地传递，直到有一个请求处理器处理完成为止，实现高效灵活的请求处理与分发。
主要涉及三个角色：
- 抽象处理器（Handler）：定义了一个处理请求的接口，并维护了一个后继处理器对象。
- 具体处理器（ConcreteHandler）：实现了处理请求的接口，并决定能否处理该请求。如果不能处理，则将请求转发给后继处理器。
- 客户端（Client）：创建一个请求处理器对象，并将其添加到责任链中。
优点：
- 降低耦合度：责任链模式将请求的发送者和接收者解耦，请求会从链的开端一直沿着链传递到链的结尾，期间每个节点只需要关注自己的处理逻辑，从而降低了节点之间的耦合度。
- 灵活性增强、可拓展性好：责任链模式可以动态地增加或删除节点对象，改变链中节点对象的调用顺序，灵活的修改或者拓展系统流程。
缺点：
- 链太长时，会降低系统性能和效率
- 请求不一定可以被处理，可能存在到达链的末尾，仍然没有合适的处理节点对其进行处理，这时候需要特殊的处理机制来处理这种情况。
- 调试困难：如果链中某个节点的调用出现问题，可能会导致整个链的请求无法被处理，导致调试时需要逐一排查。
结构型
适配器（包装）模式
将一个类的接口变换成客户端锁期待的另一种接口，从而使原本因接口不匹配而无法工作在一起的两个类能够在一起工作。
优点：
- 可以让没有任何关系的类在一起运行
- 增加了类的透明性
- 提高了类的复用度