文章目录

架构设计
- 为什么要进行技术框架的设计
六大设计原则
- 一、单一职责原则
- 二、开闭原则
- 三、依赖倒置原则
- 四、接口分离原则
- 五、迪米特法则（又称最小知道原则）
- 六、里氏替换原则
- 案例诠释
安卓主流开发技术框架
- 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;
    }
}

工厂模式

简单工厂

简单工厂模式提出是为了实现在创建一个对象时，不向客户暴露内部细节，只提供一个创建对象的通用接口。（基于了迪米特法则/最小知道原则）
简单工厂把实例化的操作单独放到一个类中，这个类就成为简单工厂类，让简单工厂类来决定应用用哪个具体子类来实例化。
这样做能把客户类和具体子类的实现解耦，在业务中我们往往有多个客户类，如果客户类要知道所有子类的细节，一旦子类发生改变，那么所有的客户类都要修改。使用工厂模式则只需要修改工厂类，并在需要子类的客户类使用时修改接口参数即可。