设计模式前篇

一、设计模式从何而来

设计模式起源于建筑领域，是前人总结的一种在特定环境下行之有效的解决方案

二、设计模式是什么

设计模式是一套被反复验证过的代码设计经验总结，使用设计模式能让我更好的理解并提升代码的可读性和简化性

三、都有哪些设计模式

四、学习设计模式都需要那些前置知识

图形往往更容易被人所理解，因为图形的信息比文字更加直白和易懂，文字往往需要人去联想和思考，同时，图形也更容易被记忆。

UML类图

类（class）

类封装了属性和行为，是举行相同属性和行为的对象集合的总称。

类一般由如下组成：

类名: 类的名称。
类的属性: 类的属性一般包含public、private、protected三类，用符号"+"、"-"、"#"表示。语法: 可见性属性名称:属性类型 $=属性默认值$
类的行为： 类的行为也就是类中包含的方法，语法：可见性方法名( $参数列表$ ): $返回值类型$ 如果无参数就（）即可，无返回值直接void即可。

类之间的关系

关联关系

关联关系是最常见的关系，一般表示一类对象和另外一类对象之间的联系，例如：班级和学生，公司和员工等。

java 复制代码

public class Members{
    private Account account;//成员变量
}
public class Account{
    private String accountNo;
    private String accountName;
}

继承关系

继承关系表示的是父子关系。

java 复制代码

public class Animal{
    private String name;
    private String type;
}
public class Pig extends Animal{
    private String hair;
}
public class Dog extends Animal{
    private String hair;
}

接口和实现关系

java 复制代码

public interface Worker{
    void doWork();
}
public class Doctor implements Worker{
    private String name;
    @Override
    public void doWork() {
        System.out.println("docker is working");
    }
}
public class Police implements Worker{
    private String name;
    @Override
    public void doWork() {
        System.out.println("Police is working");
    }
}

面向对象设计原则

单一职责原则

一个类只负责一个领域中的相应的职责。

单一职责原则是实现高内聚、低耦合的体现，看起来很简单但也很复杂，主要复杂在如何定义一个类的单一责任。

开闭原则

一个类或者一个接口应该对扩展开放，对修改关闭，保证尽量在不修改的原有代码的情况下，实现功能的扩展。

一个系统随着不断的版本迭代，需求的增加，应该尽量保证框架的稳定性，符合开闭原则的框架应该非常方便的支持扩展，只有这样才能保证软件的稳定性和可维护性。

里氏替换原则

所有使用到父类的地方，必须能透明的使用其子类对象。

软件中，父类替换成子类不应该产生错误，但是反之，子类替换成父类则不一定；例如：喜欢小动物，那我一定喜欢小狗，但是你不能说我喜欢小狗我就一定喜欢所有动物，因为我不喜欢蛇。里氏替换原则应该将父类采用抽象类或者接口的形式来保证，子类实现父类的接口，程序运行时，子类实例替换父类实例，可以方便的扩展系统功能，如果需要增加新的功能只需要添加新的子类来实现父类的方法即可。

依赖倒置原则

抽象不应该依赖于细节而是细节依赖于抽象，就是要针对接口编程。

面向接口编程的意思是，尽量使用接口或者抽象类来进行属性的定义，方法的声明，一个具体的子类应该只有父类或者接口的抽象方法的实现，而不一应该在由别的方法，否则父类就无法调用子类的其他方法。

接口隔离原则

具体的业务不应该依赖那些它不需要的接口，接口的功能应该单一化，而不是报所有的功能都放在一个接口里面，如果功能都放在一个接口里面，具体的业务也许只是需要其中一个功能而被迫取实现所有的功能，是一种资源的浪费

组合复用原则

实际的业务应该尽量使用组合关系而不是继承关系来达到复用的结果

一般来说，如果两个对象之间是"has-a"的关系，应该需要使用组合的关系，如果是"is-a"的关系应该考虑使用继承来实现。

迪米特原则

一个模块应该尽可能的减少和其他模块的关联。一个模块的修改应该尽量减少对别的模块的影响，这样就更便于扩展和维护