全栈开发笔记

设计模式

目的

设计模式是为了让程序具有更好的：

代码重用性
可读性
可扩展性
可靠性
高内聚、低耦合的特性

七大原则

在编程时应当遵守的原则，也是各种设计模式的基础、依据。

开闭原则
单一职责原则
接口隔离原则
依赖倒转原则
里氏替换原则
迪米特法则
合成复用原则

开闭原则 OCP

Open Closed Principle。编程中最基础、最重要的设计原则。开闭原则规定软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的。

这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。该特性在产品化的环境中是特别有价值的，在这种环境中，改变源代码需要代码审查，单元测试以及诸如此类的用以确保产品使用质量的过程。遵循这种原则的代码在扩展时并不发生改变，因此无需上述的过程。
伯特兰·迈耶提出。这一想法认为一旦完成，一个类的实现只应该因错误而修改，新的或者改变的特性应该通过新建不同的类实现。新建的类可以通过继承的方式来重用原类的代码。衍生的子类可以或不可以拥有和原类相同的接口。
个人理解：不用修改某个对象（类、模块、函数等）的源代码，就能扩展其功能 以 OCP 思想为基础，去理解以下原则

单一职责原则 SRP

Single responsibility principle。对类来说，一个类应该只负责一项职责。如类A负责两个不同的职责：职责1、职责2。当职责1需求变更而改变类A时，可能造成职责2执行错误。所以需要将类A的粒度按职责分解为A1,A2。

例子

v1.0.0


x
package fun.hara;
public class Demo {
    public static void main(String[] args) {
        new Vehicle("汽车").run();
        new Vehicle("摩托车").run();
    }
}
class Vehicle{
    private String name;
    public Vehicle(String name) {
        this.name = name;
    }
    public void run(){
        System.out.println(name + "运行在公路上");
    }
}

上述代码中，Vehicle的run()方法处理了不同交通工具的运行。即有多项职责。
此时，若我们禁止摩托车运行在公路上，此时修改run()方法可能会造成其他交通工具的运行错误。或者，我们新增一种交通工具，如飞机，很明显当前run()方法不能兼容，而去修改run()方法可能又会带来一系列新的问题。

v2.0.0


xxxxxxxxxx
package fun.hara;
public class Demo {
    public static void main(String[] args) {
        new CarVehicle("汽车").run();
        new MotorcycleVehicle("摩托车").run();
        new AirplaneVehicle("飞机").run();
    }
}
class CarVehicle{
    private String name;
    public CarVehicle(String name) {
        this.name = name;
    }
    public void run(){
        System.out.println(name + "运行在公路上");
    }
}
class MotorcycleVehicle{
    private String name;
    public MotorcycleVehicle(String name) {
        this.name = name;
    }
    public void run(){
        System.out.println(name + "不允许上路");
    }
}
class AirplaneVehicle{
    private String name;
    public AirplaneVehicle(String name) {
        this.name = name;
    }
    public void run(){
        System.out.println(name + "飞翔在天空上");
    }
}

解决了v1.0.0的问题。
当代码逻辑足够简单时，为减少代码量，也可以使用v3.0.0的方式。

v3.0.0


xxxxxxxxxx
public class Demo{
    public static void main(String[] args) {
        new Vehicle("汽车").carRun();
        new Vehicle("摩托车").motorcycleRun();
        new Vehicle("飞机").airplaneRun();
    }
}
class Vehicle{
    private String name;
    public Vehicle(String name) {
        this.name = name;
    }
    public void carRun(){
        System.out.println(name + "运行在公路上");
    }
    
    public void motorcycleRun(){
        System.out.println(name + "不允许上路");
    }
    
    public void airplaneRun(){
        System.out.println(name + "飞翔在天空上");
    }
}

上述代码在方法级别保持单一职责原则。但前提是逻辑足够简单，类中的方法足够少。

小结

单一职责原则：

降低类的复杂度。一个类只负责一项职责。
提高类的可读性，可维护性。
降低变更引起的风险。
通常情况下，应当遵守SRP，只有逻辑足够简单时，类中的方法足够少时，才可以违反SRP。

接口隔离原则 ISP

Interface Segregation Principle ISP指明客户（client）不应该依赖于它不使用的方法。ISP把非常庞大臃肿的接口拆分成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。这种缩小的接口也被称为角色接口（role interfaces）。 ISP的目的是解耦，从而容易重构，更改和重新部署。

例子

v1.0.0


xxxxxxxxxx
public class Demo{
    public static void main(String[] args) {
       // main
    }
    // 只需要实现A接口的method1，method3方法
    public static void doWork1(A a){
        // doWork2
    }
    // 只需要实现A接口的method2方法
    public static void doWork2(A a){
        // doWork2
    }
}
interface A{
    void method1();
    void method2();
    void method3();
}

上述代码中，doWork1()和doWork2()方法都依赖了A接口，但他们仅需要A接口的部分方法。此时A接口的设计显然不合理，因为对于客户端，我们想要调用doWork1()和doWork2()方法都要去实现不需要的方法。
所以，我们需要对A接口进行拆分。在实际开发中，接口可能是按角色来拆分的。

v2.0.0


xxxxxxxxxx
public class Main{
    public static void main(String[] args) {
       // main
    }
    // 只需要实现A接口的method1，method3方法
    public static void doWork1(A1 a){
        // doWork2
    }
    // 只需要实现A接口的method2方法
    public static void doWork2(A2 a){
        // doWork2
    }
}
interface A1{
    void method1();
    void method3();
}
interface A2{
    void method2();
}
interface A extends A1, A2{  
}

上述代码解决了v1.0.0的问题。另外，若存在使用method1()，method2()，method3()三个方法的需要。可额外定义一个接口来继承方法对应的接口。

依赖反转原则 DIP

Dependency inversion principle DIP 是指一种特定的解耦（传统的依赖关系创建在高层次上，而具体的策略设置则应用在低层次的模块上）形式，使得高层次的模块不依赖于低层次的模块的实现细节，依赖关系被颠倒（反转），从而使得低层次模块依赖于高层次模块的需求抽象。

该原则规定：

高层次的模块不应该依赖于低层次的模块，两者都应该依赖于抽象接口。
抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。该原则颠倒了一部分人对于面向对象设计的认识方式。如高层次和低层次对象都应该依赖于相同的抽象接口。

图1中，高层对象A依赖于底层对象B的实现；图2中，把高层对象A对底层对象的需求抽象为一个接口A，底层对象B实现了接口A，这就是依赖反转。

对比传统应用架构

在传统的应用架构中，低层次的组件设计用于被高层次的组件使用，这一点提供了逐步的构建一个复杂系统的可能。在这种结构下，高层次的组件直接依赖于低层次的组件去实现一些任务。这种对于低层次组件的依赖限制了高层次组件被重用的可行性。
依赖反转原则的目的是把高层次组件从对低层次组件的依赖中解耦出来，这样使得重用不同层级的组件实现变得可能。把高层组件和低层组件划分到不同的包/库（在这些包/库中拥有定义了高层组件所必须的行为和服务的接口，并且存在高层组件的包）中的方式促进了这种解耦。由于低层组件是对高层组件接口的具体实现，因此低层组件包的编译是依赖于高层组件的，这颠倒了传统的依赖关系。众多的设计模式，比如插件，服务定位器或者依赖反转，则被用来在运行时把指定的低层组件实现提供给高层组件。
应用依赖反转原则同样被认为是应用了适配器模式，例如：高层的类定义了它自己的适配器接口（高层类所依赖的抽象接口）。被适配的对象同样依赖于适配器接口的抽象（这是当然的，因为它实现了这个接口），同时它的实现则可以使用它自身所在低层模块的代码。通过这种方式，高层组件则不依赖于低层组件，因为它（高层组件）仅间接的通过调用适配器接口多态方法使用了低层组件，而这些多态方法则是由被适配对象以及它的低层模块所实现的。

例子

v1.0.0


xxxxxxxxxx
public class Demo{
    public static void main(String[] args) {
       new Worker().doWork(new JapaneseTool());
    }
}
class Worker{
    public void doWork(JapaneseTool tool){
        tool.screwdriver("螺丝钉1");
        tool.screwdriver("螺丝钉2");
    }
}
class JapaneseTool{
    public void screwdriver(String screw){
        System.out.println("使用日本螺丝刀拧螺丝钉：" + screw);
    }
}

上述代码中，可以将Worker视为高层的类，JapaneseTool视为底层的类，Worker依赖了JapaneseTool，非常紧密的耦合。若我们需要将JapaneseTool，替换成ChineseTool，则要去修改Worker的源代码。难道每次替换都要去修改Worker的源代码吗？
不可能。合理的做法是提供一个接口，让doWork()方法依赖于该接口，而不是依赖具体的实现类。类似于JDBC。

v2.0.0


xxxxxxxxxx
public class Demo{
    public static void main(String[] args) {
       new Worker().doWork(new JapaneseTool());
       new Worker().doWork(new ChineseTool());
    }
}
class Worker{
    public void doWork(ITool tool){
        tool.screwdriver("螺丝钉1");
        tool.screwdriver("螺丝钉2");
    }
}
interface ITool{
     void screwdriver(String screw);
}
class JapaneseTool implements ITool{
    public void screwdriver(String screw){
        System.out.println("使用日本螺丝刀拧螺丝钉：" + screw);
    }
}
class ChineseTool implements ITool{
    public void screwdriver(String screw){
        System.out.println("使用国产螺丝刀拧螺丝钉：" + screw);
    }
}

小结

DIP：

解耦
提高程序稳定性
提高程序扩展性，便于维护和优化。

里氏替换原则 LSP

Liskov Substitution Principle。里氏替换原则中说，任何基类可以出现的地方，子类一定可以出现。

子类可以扩展父类的功能，但不能改变父类原有的功能。即子类尽量不要重写父类的方法。
如父类存在add(int a, int b)方法，是将a和b相加，而子类重写后，将a和b相减。此时若用子类去替换父类对象，就会出错。
LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
如此，问题产生了：“我们如何去度量继承关系的质量？” Liskov于1987年提出了一个关于继承的原则“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“继承必须确保超类所拥有的性质在子类中仍然成立。” 也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系。

形象理解

来源：百度百科我们来研究一下LSP的实质。学习OO的时候，我们知道，一个对象是一组状态和一系列行为的组合体。状态是对象的内在特性，行为是对象的外在特性。LSP所表述的就是在同一个继承体系中的对象应该有共同的行为特征。这一点上，表明了OO的继承与日常生活中的继承的本质区别。

举一个例子：生物学的分类体系中把企鹅归属为鸟类。我们模仿这个体系，设计出这样的类和关系。类“鸟”中有个方法fly，企鹅自然也继承了这个方法，可是企鹅不能飞阿，于是，我们在企鹅的类中覆盖了fly方法，告诉方法的调用者：企鹅是不会飞的。这完全符合常理。但是，这违反了LSP，企鹅是鸟的子类，可是企鹅却不能飞！需要注意的是，此处的“鸟”已经不再是生物学中的鸟了，它是软件中的一个类、一个抽象。有人会说，企鹅不能飞很正常啊，而且这样编写代码也能正常编译，只要在使用这个类的客户代码中加一句判断就行了。但是，这就是问题所在！首先，客户代码和“企鹅”的代码很有可能不是同时设计的，在当今软件外包一层又一层的开发模式下，你甚至根本不知道两个模块的原产地是哪里，也就谈不上去修改客户代码了。客户程序很可能是遗留系统的一部分，很可能已经不再维护，如果因为设计出这么一个“企鹅”而导致必须修改客户代码，谁应该承担这部分责任呢？（大概是上帝吧，谁叫他让“企鹅”不能飞的。^_^）“修改客户代码”直接违反了OCP，这就是OCP的重要性。违反LSP将使既有的设计不能封闭！ LSP并没有提供解决这个问题的方案，而只是提出了这么一个问题。

契约式设计 Dbc

于是，工程师们开始关注如何确保对象的行为。1988年，B. Meyer提出了Design by Contract（契约式设计）理论。DbC从形式化方法中借鉴了一套确保对象行为和自身状态的方法，其基本概念很简单：

Pre-condition: 每个方法调用之前，该方法应该校验传入参数的正确性，只有正确才能执行该方法，否则认为调用方违反契约，不予执行。这称为前置条件(Pre-condition)。
Post-Condition: 一旦通过前置条件的校验，方法必须执行，并且必须确保执行结果符合契约，这称之为后置条件(Post-condition)。
Invariant: 对象本身有一套对自身状态进行校验的检查条件，以确保该对象的本质不发生改变，这称之为不变式(Invariant)。

以上是单个对象的约束条件。为了满足LSP，当存在继承关系时，子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松；而子类中方法的后置条件必须与超类中被覆盖的方法的后置条件相同或者更为严格一些OO语言中的特性能够说明这一问题：继承并且覆盖超类方法的时候，子类中的方法的可见性必须等于或者大于超类中的方法的可见性，子类中的方法所抛出的受检异常只能是超类中对应方法所抛出的受检异常的子类。以上这些特性都非常好地遵循了LSP。但是DbC呢？很遗憾，主流的面向对象语言（不论是动态语言还是静态语言）还没有加入对DbC的支持。但是随着AOP概念的产生，相信不久DbC也将成为OO语言的一个重要特性之一

例子


xxxxxxxxxx
public class Demo{
    public static void main(String[] args) {
       A a1 = new A();
       A a2 = new B();
       System.out.println(a1.add(1,2));
       System.out.println(a2.add(1,2));
    }
}
class A{
    public int add(int a, int b){
       return a + b;
    }
}
class B extends A{
    public int add(int a, int b){
       return a - b;
    }
}

显然在上述代码中，B类所覆盖的add()方法破坏了该行为在父类中的含义。在实际开发中，可能是无意的。
想像你在实际工作中，去调用某个类的insert()方法（希望这个方法不是你写的#滑稽），然而这个方法竟然帮你执行了删除操作！！

小结

使用继承时，遵循LSP，尽量不要覆写父类方法。
LSP告诉我们，继承实际上增强了两个类的耦合。所以尽量考虑是否可以使用聚合、组合等其他手段来解决问题。

迪米特法则 LoD

Law of Demeter。迪米特法则又叫作最少知识原则（Least Knowledge Principle，LKP），就是说一个对象应当对其他对象有尽可能少的了解，不和陌生人说话。

一个对象应该对其他对象保持最少的了解
类与类关系越密切，耦合度越大
一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息。
迪米特法则还有个更简单的定义：只与朋友通信

朋友条件

当前对象本身（this）
形参
实例变量。若实例变量是一个集合，那么集合中的元素也都是朋友。
当前对象所创建的对象。

优缺点及模式

迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。
迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。
门面模式（Facade）和中介模式（Mediator），都是迪米特法则应用的例子。

合成复用原则 CRP

Composite Reuse Principle。原则是尽量使用合成、聚合的方式，而不是使用继承。

消息队列

典型应用场景

异步、削峰、解耦

异步

如购物订单下单流程，由若干个小操作完成，此时就可能造成较长的时延。

面对接口Rt（ResponseTime响应时间）有要求的场景，则必须进行优化。
在下单流程中，优惠券扣除、积分增减，短信发送等流程，实际是没有先后顺序要求的，即可以同时进行。
疑问：好像多线程也能解决该问题？为什么要上消息队列呢？