设计模式有六大原则，

单一职责原则

（功能）一个类只负责一项任务
就一个类而言，引起它变化的原因应该有且仅有一个
避免一个类过度的把一些功能耦合在一起，即不要让这个类承担太多的功能职责，不会出现功能1改变，会影响功能2功能3，等其他功能，
举个例子
比如我想喂养一只宠物，要求不高，能吃能睡就行

public class Pet{
  public void eat(){
    System.out.print("吃得饱");
  }
}

然后去宠物店了

public class PetStore{
        public void buy(){
            System.out.print("宠物店买一只宠物");
        }
    }

然后宠物店老板热情的推荐了二哈，金毛，卡布拉多，等等，并且分别介绍了他们的饮食习惯的不同

public class Pet{
        public void eat(String kind){
            if (kind.equals("二哈")){
                System.out.print("二哈拆家，吃卫生纸");
            }else if (kind.equals("拉不拉猪")){
                System.out.print("拉不拉猪吃得多，拉得多");
            }else if...
            ...
        }
    }

到最后，都不知道要把谁带回家，要知道就为二哈，拉布拉多，单独建立一个类，自己负责自己的吃喝，就可以不用管其他的了

开放封闭原则

类，模块，函数都应该是可扩展的，但不可修改
对于扩展开放，对于修改就关闭，需求千变万化，我们写代码最初就应该考虑好以后的扩展性，总不能需求改了，代码就得天翻地覆吧，做完了查询功能，需求有增加了，删除，修改，不能改以前的代码，要去加代码的扩展
举个例子
买了一只二哈回家，开始养

public class PetStore{
        public void host(){
            System.out.print("养狗");
        }
    }

相处几天，发现除了每天喂食，狗还每天到处拉屎，再给他铲屎，出门一次，回家发现拆家了，

//按照开发封闭原则，这么写是不对滴，毕竟代码已经改了...
public class PetStore{
        //传参，根据参数值来执行喂食、遛狗、铲屎方法
        public void host(int i){
            System.out.print("养狗");
        }
    }

最后说不定还得加个炖狗的方法
采用开发封闭原则，就是“增加一个抽象的功能类”。使喂食，遛狗，铲屎，成为这个抽象类的子类，如果要加入炖狗的只需要增加一个子类就可以了，一个抽象类，每一个操作都是一个实现类，增加操作，增加实现类即可

里氏替换原则

（继承）子类只能扩展父类的功能，不能修改父类的功能
所有引用基类（父类）的地方，必须能够透明的使用器子类对象
在代码中使用父类对象的地方替换成子类的没事，反过来就不行，里氏替换原则是实现开放封闭原则的重要方式之一，尽量使用父类类型定义对象，运行时再确定子类类型，用子类对象来替换父类对象
注意的是，子类中所有的方法必须得在父类中声明，换言之子类必须实现父类声明的所有方法，这里尽量把父类声明为抽象类，接口，是子类集成父类，或者实现父类接口，并实现父类中声明的方法，在运行时，子类实例替换父类实例，即方便功能扩展，又不至于对源代码进行大的改动，若新增一个功能，新增加一个子类实现即可
例子
新建了一个类继承Pet类

public class Dog extends Pet{
        public void eat(){
            System.out.print("爱吃骨头");
        }
    }

违反规则了，虽然时继承了Pet，但是子类仅可以扩展新功能，不能改变父类原来的功能，这里如果把用到pet类的地方，换成Dog，那岂不是都吃骨头了，

依赖倒装原则

高层模块不应该依赖底层模块，他们都应该依赖抽象，抽象不依赖细节，细节依赖抽象
抽象指接口，抽象类（都不能直接被实例化）。细节指实现类（实现接口，继承抽象类），高层模块指调用端，底层模块指的是实现类，请求网络既可以用http，也可以用原生API，只需封装一个网络请求接口，创建他俩的接口实现类就行了
例子
购买宠物，当然话得买狗粮，猫粮

public class PetStore{
        public void buy(Dog dog){
            System.out.print("宠物店买一只二哈，再买狗粮");
        }
        public void buy(Cat cat){
            System.out.print("宠物店买一只加菲猫，还买猫粮");
        }
        //这里省略了鸡鸭鹅狗猪的购买方法...
    }

安装上面的方式购买，累死，换个思路，你去货架上买，老板在门口收银就可以，面对接口编程

public interface Pet{
        public void buy();
    }
public class Dog implements Pet{

    @Override
    public void buy() {
        System.out.print("买一只二哈回家，还给它买骨头吃");
    }
}

Buy方法时高层模块，买猫买狗时低层模块，依赖于抽象，扩展性强

迪米特原则（最少知道原则）

一个原件实体，应尽可能少的与其他实体发生作用
当一个模块发生修改时，应该尽可能少的减少对象间的交互和影响其他模块，若两个对象之间不发生直接通信，他俩就不会发生直接作用，如果要调用对应的方法，需要引入第三者或中介
例子
狗子生病了，去看病

public class Hospital{
        public void doctor(){
            System.out.print("医生看病");
        }
    }

医生看病得知道狗子平时有什么不良的习惯，医生直接问铲屎官就好了，

public class Owner{
        public void getInformation(){
            System.out.print("铲屎官知道狗子信息...");
        }
    }

接口隔离原则

一个类对另一个类的依赖，应该建立在最小的接口上
接口一定要细化，接口中的方法一定要少，切忌接口臃肿化
例子
所有的方法都定义在一个接口中

public interface Pet{
        public void eat();
        public void wang();//二哈汪汪叫
        public void miao();//加菲猫喵喵
    }

创建Dog类，此时接口已经变得臃肿了，有的方法没有用到根本

public class Dog implements Pet{

        @Override
        public void eat() {
            System.out.print("狗吃肉");
        }

        @Override
        public void wang() {
            System.out.print("二哈旺旺叫...");
        }

        @Override
        public void miao() {
            //加菲猫喵喵叫，这里用不到，接口已经臃肿了...
        }
    }

这里只能把接口拆分，组合实现

public interface Wang{
        public void wang();
    }

public class Dog implements Wang{
        @Override
        public void wang() {
            System.out.print("二哈旺旺叫...");
        }
    }