一、程序设计的六大原则
- 单一职责原则（Single Responsibility Principle）
一个类只负责一个功能，应该是一组相关性很高的函数、数据的封装，高内聚低耦合，对于外界而言，应该仅有一个引起它变化的原因。如果一个类中承担的职责越多，那么相当于把这些职责耦合在一起，那么类可复用性就越小。当其中一个职责发生变化时，可能会引发其他职责的变化，进而影响到其他职责的正常运作，因此要将这些职责进行分离，把不同的职责封装在不同的类中。但是，如果多个职责总是同时发生变化，那么可以把它们封装在同一个类中。
- 开闭原则（Open Closed Principle）
一个软件的实体(如类、模块、方法等)应该对扩展开发，对修改关闭。也就是说软件应该在尽量不修改原来代码的基础上进行扩展。当一个软件/应用需要升级或者维护等原因需要对原有的代码进行修改时，可能会将错误的代码引入，从而破坏原有的系统。因此当软件的需求发生改变时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改原有的代码。
- 里氏替换原则（Liskov Substitution Principle）
所有引用父类的地方，也可以透明的使用子类的对象。通俗的说就是，只要有父类出现的地方，都可以子类来替代，并且不会出现任何异常或者错误，但是反过来不行。
我们都知道继承是java的三大特性之一，可以减少很多重复的代码，但也有存在一些问题：
- 类的耦合性增加。如果父类发生了改变，子类也会随之变化。
- 降低了代码的灵活性。继承是侵入性的，父类对子类有一定的约束性，子类必须拥有父类的属性和方法。
使用里氏特换原则，可以减少由于继承带来的问题。由于使用父类的地方可以用子类来代替，因此在程序中尽量使用父类类型来定义对象，在运行时确定子类的类型，用子类的对象替换父类的对象。在运用里氏替换原则时，尽量把父类设计成接口或者抽象类。
- 依赖倒置原则（Dependence Inversion Principle）
- 高层模块不应该依赖于底层模块，都应该依赖于抽象。
- 抽象不应该依赖于细节，细节应该依赖于抽象。
依赖倒置原则在java中的表现就是，模块之间的依赖是通过抽象的，实现类之间不发生直接的依赖关系，其依赖关系都是通过接口或者抽象类产生的；接口或者抽象类不依赖实现类；实现类依赖于接口或者抽象类。
- 接口隔离原则（Interface Segregation Principle）
- 当需要依赖接口时，应该依赖多个专门的接口，而不是依赖一个庞大臃肿的接口。客户端不应该依赖它不需要的接口。
- 类之间的依赖关系应该建立在最小的接口上。
- 迪米特原则（Law of Demeter）
一个对象应该对其他的对象有最少的了解。通俗的说就是，一个类应该对自己需要调用的类了解的最少，被调用的类的内部是怎么设计的和如何复杂的，都和我没有关系。
二、程序设计的三大模式
创建型模式：对对象的实例化过程进行抽象，这使得一个系统可以不用关心这些对象是如何创建，组合，呈现的，对于类创建模式来说通过使用继承改变实例化的类，对于对象创建模式来说通过使用代理来实例化所需要的对象。
创建型模式包括：单例模式、建造者模式、原型模式、工厂方法模式、抽象工厂模式
行为型模式：行为模式不仅表达了对象和类，还表达了他们之间的交互，涉及到了对象和算法的分配。
行为型模式包括：观察者模式、责任链模式、模板方法模式、策略模式、迭代器模式、命令模式、状态模式、备忘录模式、访问者模式、中介者模式、解释器模式
结构型模式：通过对多个类和对象进行组合得到复杂结构的类，一般使用继承或者成员变量引用形式来实现。
结构型模式包括：代理模式、装饰器模式、适配器模式、外观模式、组合模式、享元模式、桥接模式
三、23种设计模式
1、创建型模式
2、行为型模式
3、结构型模式
四、参考
设计模式之禅(第二版)-秦小波
