设计模式七大原则及代码示例

zoukankan html css js c++ java

设计模式七大原则及代码示例
七大原则：
1. 单一职责原则；
2. 接口隔离原则；
3. 依赖倒转原则；
4. 里氏替换原则；
5. 开闭原则ocp；
6. 迪米特法则；
7. 合成复用原则。
设计模式其实包含了面向对象的精髓，封装、继承、多态。

一、单一职责原则

对于类来说，一个类应该只负责一项职责。

假设A负责两个不同的职责1和2，如果1的内容需要改变，影响了2，那可能2会执行错误，所以需要将A分为两个类。

1.1 示例
```
public class SingleResponsibility1 {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("汽车");
        vehicle.run("摩托车");
        vehicle.run("飞机");
    }
}

class Vehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在地上跑");
    }
}
```
对于一个完成交通工具的类Vehicle来说，显然对不同的对象、汽车和飞机，提供的服务不应该都是在地上跑，并且修改之后，肯定会影响到其中一类对象的功能，所以按照单一职责，那就应该拆开，成两个类。

1.2 改进版本 1
```
public class SingleResponsibility2 {
    public static void main(String[] args) {
        RoadVehicle roadVehicle = new RoadVehicle();
        roadVehicle.run("摩托车");
        roadVehicle.run("汽车");
        AirVehicle airVehicle = new AirVehicle();
        airVehicle.run("飞机");
    }
}

class RoadVehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在地上跑");
    }
}
class AirVehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在天上飞");
    }
}
```
但是这么写又有了新的问题：那就是类分解的时候，客户端代码也要改，调用方式改了。因此可以直接更改本来的Vehicle类，变成我们的第三种写法.

1.3 改进版本 2
```
public class SingleResponsibility3 {
    public static void main(String[] args) {
        Vehicle2 vehicle2 = new Vehicle2();
        vehicle2.runRoad("汽车");
        vehicle2.runWater("轮船");
        vehicle2.runAir("飞机");
    }
}

class Vehicle2{
    public void runRoad(String vehicle){
        System.out.println(vehicle+"在公路上跑");
    }
    public void runAir(String vehicle){
        System.out.println(vehicle+"在天上飞");
    }
    public void runWater(String vehicle){
        System.out.println(vehicle+"在水里游");
    }
}
```
这种写法，显然更加方便，相比第一种，没有更改类的声明方式，只是在类内部增加了方法的各司其职，可以看出来，虽然没有在类级别上严格遵循单一职责原则，但是在方法级别上严格遵循了单一职责原则，相比之下比方法2更合适。

1.4 总结单一职责原则
1. 降低类的复杂度，一个类只负责一项职责（上面的例子因为过于简单，所以看起来第三个写法更有效）；
2. 提高类的可读性、可维护性，降低变更带来的风险；
3. 通常情况下，我们应该遵守这个职责，只有在逻辑足够简单的时候，才可以在代码级别违反这个原则，也就是上面的，改为在方法级别保持单一职责原则。
二、接口隔离原则

接口隔离（Interface Segregation Principle）

意思是说，如果某一个类对另一个类的依赖通过的是接口，那么这个类对另一个类的依赖应该建立在最小的接口上，如果不是最小接口，则需要拆。

2.1 示例

例如如下的用例图：

A 和 B 是 Interface1 的实现类，所以必须实现它的 4 个方法，C 和 D 分别依赖于这个接口，使用 A 和 B 里面对应的方法，但不是全部，C 使用前三个方法，D 使用后三个方法，如果按照类图实现，代码会如下所示：
```
interface Interface1{
    void fuc1();
    void fuc2();
    void fuc3();
    void fuc4();
}

class A implements Interface1{
    public void fuc1() {System.out.println("A实现了fuc1");}
    public void fuc2() {System.out.println("A实现了fuc2");}
    public void fuc3() {System.out.println("A实现了fuc3");}
    public void fuc4() {System.out.println("A实现了fuc4");}
}

class B implements Interface1{
    public void fuc1() {System.out.println("B实现了fuc1");}
    public void fuc2() {System.out.println("B实现了fuc2");}
    public void fuc3() {System.out.println("B实现了fuc3");}
    public void fuc4() {System.out.println("B实现了fuc4");}
}
//C通过接口Interface1依赖，使用A这个实现类，但是只用A的前两个方法
class C {
    public void depend1(Interface1 i){
        i.fuc1();
    }
    public void depend2(Interface1 i){
        i.fuc2();
    }
    public void depend3(Interface1 i){
        i.fuc3();
    }
}
//D通过接口Interface1依赖，使用B这个实现类，但是只用B的后两个方法
class D {
    public void depend2(Interface1 i){
        i.fuc2();
    }
    public void depend3(Interface1 i){
        i.fuc3();
    }
    public void depend4(Interface1 i){
        i.fuc4();
    }
}
```
显然，A 和 B 两个实现类都做了多余的工作，也就是 C 和 D 依赖的这个接口有些方法是他们不需要的，这个接口写的不好。

2.2 改进

根据接口隔离原则，我们应该将其拆成满足最小接口的类型，也就是说多余的我们全都不应要，所以接口 Interface1 应该拆分为三个接口，接口 1 里面有方法 1 ，接口 2 里面有方法 23，接口 3 里面有方法 4，这样实现的时候A和B两个类就更加清晰，修改后的类图如下：

那么，这样 A 和 B 实现的方法就是需要的方法，不会有多余的方法，C 和 D 的依赖也就更加清楚，满足 最小接口。
```
interface Interface11{
    void fuc1();
}
interface Interface12{
    void fuc2();
    void fuc3();
}
interface Interface13{
    void fuc4();
}
class A1 implements Interface11,Interface12{
    public void fuc1() {System.out.println("A实现了接口1的fuc1");}
    public void fuc2() {System.out.println("A实现了接口2的fuc2");}
    public void fuc3() {System.out.println("A实现了接口2的fuc3");}
}
class B1 implements Interface12,Interface13{
    public void fuc2() {System.out.println("B实现了接口2的fuc2");}
    public void fuc3() {System.out.println("B实现了接口2的fuc3");}
    public void fuc4() {System.out.println("B实现了接口3的fuc4");}
}
class C1{
    public void depend1(Interface11 i){
        i.fuc1();
    }
    public void depend2(Interface12 i){
        i.fuc2();
    }
    public void depend3(Interface12 i){
        i.fuc3();
    }
}
class D1{
    public void depend2(Interface12 i){
        i.fuc2();
    }
    public void depend3(Interface12 i){
        i.fuc3();
    }
    public void depend4(Interface13 i){
        i.fuc4();
    }
}
```
这种写法就是遵循了接口隔离原则

客户端使用的时候：
```
    C1 c = new C1();
    c.depend1(new A1());//C类通过接口依赖（使用）的是A类
    c.depend2(new A1());
    c.depend3(new A1());
    D1 d = new D1();
    d.depend2(new B1());//D类通过接口依赖（使用）的是B类
    d.depend3(new B1());
    d.depend4(new B1());
```
三、依赖倒转原则

依赖倒转原则 ( Dependence Inversion Principle ) 指的是：
1. 高层模块不应该依赖低层模块，二者都应该依赖其抽象；
2. 抽象不应该依赖细节，细节应该依赖抽象；
3. 依赖倒转的核心思想是面向接口编程。
为什么要有依赖倒转原则：主要是因为，相对于细节的多变，抽象的东西要稳定的多，以抽象为基础搭建的架构比以细节为基础的架构稳定的多，在java种，抽象指的就是接口或者抽象类，细节就是具体的实现类，抽象类制定好规范，展现细节的任务交给实现类去做。

依赖倒转原则需要注意：
1. 底层模块尽量都要有抽象类或接口，或者两者都有，程序的稳定性会更好；
2. 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象之间，就存在一个缓冲层，利于程序扩展和优化；
3. 继承时遵循里氏替换原则。
例如：有一个功能，一个Person类，要有一个接收消息的功能。

3.1 示例
```
public class DependencyInversion1 {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
    }
}
class Email{
    public String getInfo(){
        return "电子邮件信息";
    }
}
class Person{
    public void receive(Email email){
        System.out.println(email.getInfo());
    }
}
```
因为Person类需要的接受是一个功能，消息应该是另一个类，所以还有一个Email类。那么这种写法，显然直接犯在Person类里依赖了Email类，也就是上面所说的”高层模块依赖底层模块“。

那么这么写可能会带来哪些问题呢？

对于Person类，接受的这个动作可以扩展，如果要接受的不仅仅是Email，是很多短信、微信等信息，那么在新增短信、微信类的同时，Person类里要新增对应的方法，改动基本是所有的都改动。

按照依赖倒转原则，对于Email、短信这些不同的类，应该将他们抽象出一个接口，然后他们实现接口，这样的话，对于Person类，他的接受方法，就是对这个抽象接口的依赖，而不是直接依赖这些不同的实现类。

3.2 改进
```
public class Dependency1 {
    public static void main(String[] args) {
        Person1 person1 = new Person1();
        person1.receive(new Email1());
    }
}
interface IReceiver{
    public String getInfo();
}
class Email1 implements IReceiver{
    public String getInfo() {
        return "电子邮件信息:";
    }
}
class Person1{
    public void receive(IReceiver receiver){
        System.out.println(receiver.getInfo());
    }
}
```
在客户端的调用方式也是几乎一样的，运行结果是一样的，同时，因为Person依赖的是抽象的接口而不是具体的Email。

当我们想要增加一个接受的类的时候，平行增加，同时都去实现接口里面的方法就可以，Person类不用做改变，那么调用的时候传入参数去变成具体的实现类就可以。
```
//扩展
class Wechat implements IReceiver{
    public String getInfo() {
        return "微信消息：";
    }
}
```
那么main方法的客户端只需要：
```
person1.receive(new Wechat());
```
就可以。

3.3 扩展：依赖关系传递的三种方式

依赖关系的传递一般有三种方式：
1. 接口传递；
2. 构造方法传递；
3. setter方法传递。
第一种：
```
//方式1：通过接口传递依赖
interface IOpenandClose{
    public void open(ITV itv);
}
interface ITV{
    public void play();
}
class OpenandClose implements IOpenandClose{
    public void open(ITV itv) {
        itv.play();
    }
}
```
可以看到，因为第一个接口依赖于第二个接口，那么实现第一个接口的时候，就需要实现对应的方法，把接口作为参数，实现了依赖的传递。

第二种：
```
//方式2，通过构造方法传递依赖
interface IOpenandClose2{
    public void open();
}
interface ITV2{
    public void play();
}
class OpenandClose2 implements IOpenandClose2{
    public ITV2 itv2;
    public OpenandClose2(ITV2 itv2){
        this.itv2 = itv2;
    }
    public void open() {
        this.itv2.play();
    }
}
```
通第一个接口和第二个接口虽然没有直接写明依赖，但是依赖体现在实现类里，实现类里通过构造方法传入一个参数，才能进行open方法的实现，所以在构造方法的部分体现了依赖关系。

第三种：
```
//方式3，通过set方法传递依赖
interface IOpenandClose3{
    public void open();
    public void setTV(ITV3 itv3);
}
interface ITV3{
    public void play();
}
class OpenandClose3 implements IOpenandClose3{
    private ITV3 itv3;
    public void setTV(ITV3 itv3) {
        this.itv3 = itv3;
    }
    public void open() {
        this.itv3.play();
    }
}
```
其实和第一种类似，不过没有在open的地方直接依赖，而是分成两个步骤，先给声明的ITV初始化，再进行使用，这样依赖也就传递成功了。

使用三种示例的方法，我们都用到一个ITV的实现类，实现一个play方法，然后调用开关这个类，体现开关接口的依赖性。比如第一种是
```
class Sumsang implements ITV{
    public void play() {
        System.out.println("三星电视开机啦");
    }
}
```
然后在主方法里调用就是：
```
OpenandClose close = new OpenandClose();
close.open(new Sumsang());
```
因为使用开关机的时候，这个方法就是通过接口参数才能调用，所以这是第一种接口传递。

第二种就只用：
```
OpenandClose2 close2 = new OpenandClose2(new Sony());
close2.open();
```
虽然open没有参数，但是依赖是通过构造方法传递的。

第三种情况：
```
OpenandClose3 close3 = new OpenandClose3();
close3.setTV(new Xiaomi());//如果不先set，就会报空指针close3.open();
```
四、里氏替换原则

面向对象中继承的问题：
1. 父类实现好的方法，实际上设定了规范，虽然不强制要求子类都要遵守，到那时如果子类对这些方法进行了修改，会对整个继承体系造成破坏；
2. 如果使用继承会给程序带来入侵性，使得移植性降低，增加对象之间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，会影响所有子类；
3. 那么，如何在编程中正确使用继承呢？=> 里氏替换原则
里氏替换：
1. 里氏替换原则：如果每个类型 T1 的对象 o1 ，都有类型 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型，也就是说，引用基类（父类）的地方必须能透明的使用其子类（派生类）的对象。
2. 使用继承的时候，遵循里氏替换原则，也就是尽量不要重写父类的方法；
3. 这个原则告诉我们，继承让两个类的耦合性增强了，适当情况下，可以通过聚合、组合、依赖来解决问题。
如何理解这个原则呢，假如一个父类是 A，B extends A，结果把 A 类的所有方法都重写了，那肯定A类的对象所有行为都变化了，另一方面，B 还要继承 A 类纯属有病。适当的，A 和 B 更适合于，继承同一个更加基础的类 C，重新整理，这样解决这个问题会比较合适。

4.1 示例

例如：
```
class A{
    public int func1(int a, int b){
        return a - b;
    }
}
class B extends A{
    public int func1(int a, int b){
        return a + b;
    }
    public int func2(int a, int b){
        return func1(a, b)+9;
    }
}
```
不管是无意还是有意，B 继承 A 的时候把 func1 重写了。

显然，这样 B 以为被正常调用的时候，求a-b的 func1 ，却输出了和调用 a 的 func 1不一样的结果。（可能例子不是很恰当，但是如果更复杂的情况下，调用一个子类的某一个方法，方法名是一样的，肯定会认为功能是一样的）

实际开发过程中，就是因为一些重写父类方法来完成新功能的操作，让整个继承体系的复用性变差，特别是用到多态比较多的时候。

通用的做法就是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系来替代。

4.2 改进
```
//更加基础的类
class Base{

}
class A1 extends Base{
    public int func1(int a, int b){
        return a - b;
    }
}
class B1 extends Base{
    public int func1(int a, int b){
        return a + b;
    }
    public int func2(int a, int b){
        return func1(a, b)+9;
    }
    //如果b要使用到A的方法，使用组合的关系
    private A1 a1 = new A1();
    //仍然使用A的方法
    public int func3(int a, int b){
        return this.a1.func1(a, b);
    }
}
```
那么，这样的话A和B已经没有耦合的依赖关系了，那么调用的时候，想要减法的方法就可以调用fuc3，使用加法可以调用fuc1，此时不会和A的fuc1打架或者覆盖。

五、开闭原则ocp

开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则。
1. 一个软件实体、如类，模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。用抽象构建框架，用实现扩展细节；
2. 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过已有代码实现变化；
3. 编程中遵循其他原则的目的就是遵循开闭原则。
5.1 示例
```
//绘图类，根据接受的shape不同来绘制图形，【使用方】
class GraphicEidtor{
    public void drawShape(Shape s){
        if(s.type == 1) drawRec(s);
        if (s.type == 2) drawCir(s);
    }
    public void drawRec(Shape r){
        System.out.println("矩形");
    }
    public void drawCir(Shape c){
        System.out.println("圆形");
    }
}
//基类
class Shape{
    int type;
}
//【提供方】
class Rectangle extends Shape{
    Rectangle(){
        super.type = 1;
    }
}
class Circle extends Shape{
    Circle(){
        super.type = 2;
    }
}
```
调用的时候，给draw方法传入不同的参数，会根据类型画出不同的图形，我们调用一下：
```
GraphicEidtor graphicEidtor = new GraphicEidtor();
graphicEidtor.drawShape(new Rectangle());
graphicEidtor.drawShape(new Circle());
```
这种写法还是比较好理解的，但是这种写法很不好。

那么，这种写法的问题在哪里呢？

违反了设计模式的 OCP 开闭原则，也就是不满足对扩展开放，对修改关闭。这个原则希望当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码。

比如我们想加一个图形种类，那就要将这个图形多写一个类作为【提供方】，在画图类【使用方】里增加一个对应shape类型的调用，再增加一个方法。这就是违背原则了。

5.2 改进

思路就是：创建shape作为抽象类，提供一个抽线的draw方法，那么子类实现的时候去实现draw方法，这样的话，【使用方】就不用修改代码，满足了开闭原则。

（其实说白了就是面向对象的意思，这个对象自己本身需要向外提供方法，而不是让使用方去提供方法，同时，前面四个原则里也多多多少少有用到这个思路，就是让使用方不要改动）
```
class GraphicEidtor1{
    public void drawShape(Shape1 s){
        s.draw();
    }
}
abstract class Shape1{
    int type;
    public abstract void draw();
}
class Rectangle1 extends Shape1{
    Rectangle1(){
        super.type = 1;
    }
    public void draw(){
        System.out.println("矩形");
    }
}
class Circle1 extends Shape1{
    Circle1(){
        super.type = 2;
    }
    public void draw(){
        System.out.println("圆形");
    }
}
```
这样的话，调用的写法是没有任何改变的。

但是呢，如果我们要加一个新的形状，那么就让他自己去实现方法就可以了，对于【使用方】GraphicEidtor 是修改关闭的。

六、迪米特法则

Demeter Principle 迪米特法则，又叫最少知道原则：

即一个类对自己依赖的类知道的越少越好，也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装再类的内部。对外提供public方法，不对外泄露任何信息。

迪米特法则还有个更简单的定义：只与直接的朋友通信。

什么是直接朋友？每个对象都会和其他对象之间有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系，耦合的方式有很多，依赖、关联、组合、聚合等。
其中我们称出现在成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友，也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

比如A类里面直接有用到一个B b，或者某个方法有参数fuc1(B b)；或者返回值类型是B，那么这叫做B以直接朋友的形式出现在了A里面。

比如A类里面有个方法 fuc1，fuc1用到一个 B b = new B()；这样的局部变量形式让A里面出现了B，这就是陌生的类，而不是直接朋友。

6.1 示例

比如一个应用实例：

有一个学校，下属各个学院和总部，现在要求打印出学校总部的员工ID和学院员工的ID。
代码略长，但是逻辑很简单：
```
public class Demeter1 {
    public static void main(String[] args) {
        CollegeManager collegeManager = new CollegeManager();
        collegeManager.printAllEmp(new SchoolManager());
    }
}
//学校总员工
class Employee{
    private String id;
    public void setId(String id){
        this.id = id;
    }
    public String getId(){
        return id;
    }
}
//学院员工
class SchoolEmployee{
    private String id;
    public String getId() {
        return id;
    }
    public void setId(String id) {
        this.id = id;
    }
}
//管理学院员工
class SchoolManager{
    //添加学院员工
    public List<SchoolEmployee> getAllEmployee(){
        List<SchoolEmployee> list = new ArrayList<>();
        for( int i=0; i<10; i++){
            SchoolEmployee employee = new SchoolEmployee();
            employee.setId("学院员工:"+i);
            list.add(employee);
        }
        return list;
    }
}
//学校管理类
//直接朋友类有：Employee、SchoolManager，第一个作为添加方法返回值，第二个作为输出方法的参数
//陌生类：SchoolEmployee，违背了迪米特法则
class CollegeManager{
    //添加学校员工，返回值参数Employee：直接朋友
    public List<Employee> getAllEmployee(){
        List<Employee> list = new ArrayList<>();
        for(int i=0; i<5; i++){
            Employee employee = new Employee();
            employee.setId("学校总部员工："+i);
            list.add(employee);
        }
        return list;
    }
    //输出所有员工信息
    //参数SchoolManager：直接朋友
    public void printAllEmp(SchoolManager sub){
        //SchoolEmployee：陌生朋友，局部变量的方式
        List<SchoolEmployee> list1 = sub.getAllEmployee();
        System.out.println("-----学院员工-----");
        for(SchoolEmployee e: list1){
            System.out.println(e.getId());
        }
        List<Employee> list2 = this.getAllEmployee();
        System.out.println("-----学校员工-----");
        for(Employee e: list2){
            System.out.println(e.getId());
        }
    }
}
```
这里面的问题，关于直接朋友和非直接朋友已经标注。

按照迪米特法则，上面出现了 SchoolEmployee 是陌生朋友，出现在了 SchoolManager 类里。这是非直接朋友关系的耦合，根据迪米特法则是应该避免的。

6.2 改进

其实例子写的有点故意，显然出问题的那一段，学校的输出信息部分，要输出学院的信息，没必要，解决起来把输出学院员工信息的那段，放到学院员工自己的类里面就可以了。也就是遵守了前面说的 " 尽量将逻辑封装在类的内部 "。

那么就可以把 SchoolManager 部分输出学院信息部分改成：
```
//学院员工
sub.printEmployee();
```
然后对应的输出方法，写去CollegeManager类里面，添加一个方法：
```
//输出学院所有员工的信息
public void printEmployee(){
    List<SchoolEmployee> list1 = this.getAllEmployee();//不用this也行
    System.out.println("-----学院员工-----");
    for(SchoolEmployee e: list1){
        System.out.println(e.getId());
    }
}
```
这样的话，逻辑在自己类内部，提供一个public方法供外部使用。

注意：每个类之间多多少少都会有耦合，迪米特法则只是要求降低耦合关系，而不是要求完全没有依赖关系。完全没有，就相当于每个对象干个啥都在自己类里写完，也用不着直接朋友了。

七、合成复用原则

合成复用原则：尽量使用组合/聚合的方式，而不要使用继承。

例如： A 类和 B 类，B 类想要使用 A 类的两个方法，第一个想到的是继承，但是这种做法耦合性很高，如果说仅仅是想要使用这两个方法，而没有别的根本上需要用到继承的必要性，那么可能会带来很多麻烦，比如还有别的类也继承了 A ，有必要修改 A 的时候还要考虑 B 会不会收影响。

所以尽量使用的做法就是聚合或者合成：

7.1 聚合

将 A 作为一个私有变量加入到 B 里面，在 B 里面写一个 set 方法将 A 实例化，然后去调用想要的方法，这就叫做聚合。类似于我们在前面第三个原则”依赖倒转原则“最后写的传递依赖的方式的setter方法。

7.2 组合

将 A 直接实例化在 B 里面，那么 B 创建的时候，A 就已经有了一个实例化的对象，然后调用方法，和前面的里氏替换法则后面的做法是一样的。

八、总结

其实上面的七个原则很多地方的解决方案和冲突都是有重复的部分，实际上我们总结一下核心思想就是：
1. 尽量把需要变化的部分独立出来，不要和不变的代码写在一起；
2. 如果对别的部分影响大，尽量写成接口；
3. 为了松耦合努力。（可以说七个原则这个理论本身就是非常松耦合……）
查看全文

相关阅读:
【上线复盘】20190329-一个刷新数据的接口是如何导致几十万的订单数据错误
 VS------csc.exe已停止工作解决方法
 SQLServer------存储过程的使用
 SQLServer------聚集索引和非聚集索引的区别
 SQLServer------Sql Server性能优化辅助指标SET STATISTICS TIME ON和SET STATISTICS IO ON
SQLServer------如何快速插入几万条测试数据
 SQLServer------如何让标识列重新开始计算
 SQLServer------begin tran/commit tran事务的使用方法
 SQLServer------插入数据时出现IDENTITY_INSERT错误
 Spring----Spring Boot Rest的使用方法

原文地址：https://www.cnblogs.com/lifegoeson/p/13456895.html

设计模式七大原则及代码示例

一、单一职责原则

1.1 示例

1.2 改进版本 1

1.3 改进版本 2

1.4 总结单一职责原则

二、接口隔离原则

2.1 示例

2.2 改进

三、依赖倒转原则

3.1 示例

3.2 改进

3.3 扩展：依赖关系传递的三种方式

四、里氏替换原则

4.1 示例

4.2 改进

五、开闭原则ocp

5.1 示例

5.2 改进

六、迪米特法则

6.1 示例

6.2 改进

七、合成复用原则

7.1 聚合

7.2 组合

八、总结