创建性
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）一文中详细介绍。