架构设计基础知识整理

本文最后更新于：2020年1月2日凌晨

星星点点的知识点，很早就想做这块整理了，持续维护…

I. 原则:

灵活运用，而非刻意遵循

1. 基础原则

尽量少的重复代码，低耦合(尽量小的影响)，高内聚
模块，可小到一个类，大到一个系统

模块间耦合因素

构建架构时，需要谨慎耦合的因素

模块间调用
模块间传递的数据量
模块间控制
模块间接口复杂度

模块间耦合从弱到强顺序

构建架构或简单的类时，需要根据实际情况尽量契合弱的模块间耦合关系
做到职责分明，简单轻量，尽量少的潜在性的数据流动，尽量少的相互影响，避免牵一发而动全身

非直接耦合: 相互之间没有直接关系，而是由第三方模块控制和调用
数据耦合: 通过传递java的内置数据类型通讯
标记耦合: 都引用了共同的数据结构，并且通过传递该数据结构通讯
控制耦合: 通过传递开关、标志、名字等控制信息，明显的控制选择另一个模块的功能
外部耦合: 都访问一个java的内置数据类型的全局变量
公共耦合: 都访问了一个公共代码块( 全局数据结构、公共通讯区、内存公共覆盖区等)
内容耦合: 一个模块直接修改另外一个模块的数据。

降低耦合度的方法

少用类继承，多用类接口隐藏实现细节
模块功能尽量单一
拒绝重复代码
尽量不使用全局变量(Android中的全局变量会有一些坑，因为Attach在ClassLoader上的，因此根据不同ROM的优化，可能会在未预料的情况被unload，导致数据丢失)
类成员变量与方法少用public，多用private
尽量不用硬编码(如字符串放到 res/string.xml，SQL语句做一层基于业务的封装供上层使用)
使用设计模式，尽量让模块间的耦合关系保证在数据耦合或更弱

2. 原则汇总

原则	基本概念	解决问题	基本实现
开闭原则	对扩展开发，对修改关闭	实现热拔插，解耦方式	接口、抽象
里氏代换原则	子类是父类的具体抽象，抽象并可代表父类(`Is-A`)	解释抽象化的具体原则	继承，抽象
依赖倒转原则	针对接口编程，依赖于抽象不依赖于具体	易于拓展	接口编程时类型使用基类，而不使用具体实现的子类
接口隔离原则	使用多个隔离接口，比使用单个接口要好	降低耦合	封装接口的时候，尽量用不同接口解决不同问题，尽量不要合用一个接口
迪米特法则	以实体为单位，实体之间的相互作用尽量的少	降低耦合	写一个系统架构，或模块的时候，尽量少的对外依赖
合成复用原则	优先使用合成/聚合，而非继承	可以通过引入抽象类更加灵活，相互耦合变小，更加简单	尽量将已有对象纳入到新对象中，成为新对象的一部分，而不使用继承的方式进行复用，如 `ClassLoader` 中双亲委派架构

使用组合而非继承的场景:

优先使用对象组合，而非继承

Has-A的关系，而非Is-A的关系
子类的主要目的是拓展父类，而非override或final，如果存在大量这种情况，改用组合
引入工具类，而非继承自工具类
有可能或不确定子类有可能被替换为另外一个类的子类的情况 ( 如果出现这种情况，就需要修改。因此还不如使用组合，如果有类似需求，再组合如新的对象，进行拓展即可)

继承需要注意

当已经选择使用继承时，需要注意

实现抽象方法，拓展新的特性方法，尽量少的重载父类非抽象方法
重载父类非抽象方法时: 方法前置条件(方法形参)要比父类方法更宽松，方法后置条件(方法返回值)要比父类更严格

类之间的关系与UML表示

II. 常见的模式

1. MVC 与 MVP

From http://msdn.microsoft.com/en-us/library/ff647859.aspx

MVP(Model-View_Presenter)是MVC(Model-View_Controller)的一个子集。

MVC中Controller控制全局事务，View将事件发送给Controller，Controller处理完事件同步给Model(数据库/数据模型)，View是通过所绑定的Model的改变来刷新自己。
MVP中Presenter从View中获取数据，刷新Model，当Model中的数据发生改变后，Presenter读取Model并刷新View。

2. Flux

在MVC中由于View与Model存在双向通讯，当业务逐渐复杂后，MVC势必会出现大量的View与Model交错通信的情况，这种情况是非常危险的，如:

基于这个Facebook在2017提出了一个新的架构概念叫Flux，它在Model与View的通信中间加入了Dispatcher，通过Dispatcher统一处理Mode与View的通信处理，讲究单项数据流:

3. MVVM

MVVM(View<->ViewModel->Model)

在Android中可以通过DataBinding，直接在Layout文件中绑定其ViewModel。

View: 布局
ViewModel: 负责显示数据(监听到Model中的数据变化进行显示)，以及处理用户交互(监听View布局中的用户Action)
Model: 存储内容

4. MVVM-C

MVVM-C(View-ViewModel-Callback-Model)

View: 布局
Callback: 通常可以是Fragment或Activity，用于处理用户交互(监听View布局中的用户Action)
ViewModel: 显示数据(监听Model中的数据变化进行显示)
Model: 存储内容

5. 指令分离

这样的好处很明显，当你调用一个getUser的时候，符合预期的就是获取当前的User，而数据不会被修改;
而当你执行login的时候，也就是登陆，而非为了返回数据;

执行命令型的方法返回void
查询的方法才有返回值
抛Exception而非返回错误的值

如:

// 登陆就用于登陆
UserService.login(username, password);
// 获取登陆的用户用另外的方法
User u = UserService.getUser();

6. 得墨忒耳定律

最少知识原则，尽可能少的获知有限的知识，这是一种松耦合的具体案例

每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；
每个单元只能和它的朋友交谈：不能和陌生单元交谈；
只和自己直接的朋友交谈。

如:

// 错误的方式，这种方式调用者就必须要知道ObjectB，ObjectC
objectA.getObjectB().getObjectC().doSomething();
// 正确的方式，这样调用者只需要知道ObjectA，以及其有doSomething()这个接口即可
ObjectA.doSomething()

7. “死亡参数”

当方法的参数过多或者没有严格规范时，久而久之可读性就会非常差，并且容易出现问题

当方法的参数达到或超过3个时，就要停下来思考，如果这些参数真这么紧密，为什么他们不是一个对象
当参数很多时，特别在Java中是十分影响可读性，考虑使用Builder Pattern
参入参数能采用不可变就使用不可变
当传入参数有Boolean时，考虑拆成两个方法，因为这种时候通常都是处理两种情况，更易于维护
避免传入参数有null的可能，如果允许这种情况，拆成另外一个无需传入该参数的方法，如果不允许，使用@NotNull来注解。

III. 设计模式

1. 工厂方法模式

2. 单例模式

Initialization-on-demand holder idiom

Wiki

性能高，线程安全基于JVM Class Loader保证Class唯一性线程安全的模型

public class Something {
    private Something() {}

    private static class LazyHolder {
        private static final Something INSTANCE = new Something();
    }

    public static Something getInstance() {
        return LazyHolder.INSTANCE;
    }
}