设计模式

创建性
1.原型模式——Prototype
2.创建者模式——Builder
3.简单工厂模式——Simple Factory
结构型
1.适配器模式——Adapter
2.桥接模式——Bridge
3.代理模式——Proxy

行为型

其他设计模式
生产者消费者模式
控制反转（IoC）依赖注入（DI）

六大原则

1、单一职责

一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。不过在现实开发中，这个原则是最不可能遵守的，因为每个人对一个类的哪些功能算是同一类型的职责判断都不相同。

2、开放封闭原则

对扩展开放，对修改关闭。
软件实体应该是可扩展，而不可修改的。也就是说，你写完一个类，要想添加功能，不能修改原有类，而是想办法扩展该类。有多种设计模式可以达到这一要求。

3、里氏替换原则

所有引用基类（父类）的地方必须能透明地使用其子类的对象。
当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系。也就是说接口或父类出现的地方，实现接口的类或子类可以代入，这主要依赖于多态和继承。

4、接口分离原则

不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。 不要提供一个大的接口包括所有功能，应该根据功能把这些接口分割，减少依赖。

5、依赖倒置原则

高层模块不应该依赖于低层模块，二者都应该依赖于抽象
抽象不应该依赖于细节，细节应该依赖于抽象

依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。

6、迪米特法则

一个软件实体应当尽可能少地与其他实体发生相互作用。

补充

依赖倒置原则：

理解几个点：上层，底层，抽象，细节。

举个例子一般我们会将模块分为业务层、逻辑层和数据层。
业务层就是这个模块要进行的操作，就是要做什么，逻辑层表示为了业务层需要提供的实现方式和细节，数据层即为实现业务和逻辑所需要的数据模型。
这里业务层就是上层，逻辑和数据层是底层。

抽象和具体就比较好理解，下面的Driveable是抽象，实现它的就是具体。

public interface Driveable {
    void drive();
}

class Bike implements Driveable{

    @Override
    public void drive() {
        // TODO Auto-generated method stub
        System.out.println("Bike drive.");
    }
}

class Car implements Driveable{

    @Override
    public void drive() {
        // TODO Auto-generated method stub
        System.out.println("Car drive.");
    }
}

在开发中我们是这样的编码：

public class Person {

    private Bike mBike;

    public Person() {
        mBike = new Bike();
    }

    public void out() {
        System.out.println("出门了");
        mBike.drive();
    }
}

创建了一个 Person 类，拥有一台自行车，出门的时候就骑自行车。

public class Test1 {
    public static void main(String[] args) {
        Person person = new Person();
        person.out();
    }
}

不过，自行车适应很短的距离。如果，我要出门逛街呢？自行车就不大合适了。于是就要改成汽车。

public class Person {

    private Bike mBike;
    private Car mCar;

    public Person() {
        //mBike = new Bike();
        mCar = new Car();
    }

    public void out() {
        System.out.println("出门了");
        //mBike.drive();
        mCar.drive();
    }
}

我们需要修改 Person 这个类的代码
不过，如果我要到北京去，那么汽车也不合适了，还要修改。(违反了开闭原则)
而依赖倒置原则正好适用于解决这类情况。

• 上层模块不应该依赖底层模块，它们都应该依赖于抽象。
• 抽象不应该依赖于细节，细节应该依赖于抽象

按照决策能力高低或者重要性划分，Person属于上层模块，Bike、Car属于底层模块。
上层Person不应该依赖与底层（Bike,Car），应该依赖于抽象（Driveable）

public class Person {

//  private Bike mBike;
//  private Car mCar;
    private Driveable mDriveable;

    public Person() {
        //mBike = new Bike();
        mDriveable = new Car(); // 里氏替代
    }

    public void out() {
        System.out.println("出门了");
        //mBike.drive();
        //mCar.drive();
        mDriveable.drive();
    }
}

那么，抽象不应该依赖于细节，细节应该依赖于抽象又是什么意思呢？
Driveable 是抽象，它代表一种行为，而 Bike、Car 都是实现细节。

Person 需要的是 Driveable，需要的是交通工具，但不是说交通工具一定是 Bike、Car。未来也可能是 AirPlane。

本来正常编码下，肯定会出现上层依赖底层的情况，而依赖倒置原则的应用则改变了它们之间依赖的关系，它引进了抽象。上层依赖于抽象，底层的实现细节也依赖于抽象，所以依赖倒置我们可以理解为依赖关系被改变，如果非常纠结于倒置这个词，那么倒置的其实是底层细节，原本它是被上层依赖，现在它倒要依赖与抽象的接口。

这里顺便提一下依赖注入（DI），就拿上面的例子来说，每次改变出行方式都需要Person类，如何避免这种修改呢，可以使用依赖注入的三种方式（构造注入，setter注入和接口注入）来实现。

public class Person {
    private Driveable mDriveable;

    public Person(Driveable mDriveable) {
        this.mDriveable = mDriveable;
    }

    public void out() {
        System.out.println("出门了");
        mDriveable.drive();
    }
}

依赖注入是一种编程思想，在设计模式——其他设计模式 模块中 控制反转（IoC）依赖注入（DI）一文中详细介绍。