设计模式（面向对象六大原则）（总结）

设计模式简介

设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。

面向对象设计原则。

对接口编程而不是对实现编程。
优先使用对象组合而不是继承。

设计模式在软件开发中的两个主要用途。

开发人员的共同平台

设计模式提供了一个标准的术语系统，且具体到特定的情景。例如，单例设计模式意味着使用单个对象，这样所有熟悉单例设计模式的开发人员都能使用单个对象，并且可以通过这种方式告诉对方，程序使用的是单例模式。

最佳的实践

设计模式已经经历了很长一段时间的发展，它们提供了软件开发过程中面临的一般问题的最佳解决方案。学习这些模式有助于经验不足的开发人员通过一种简单快捷的方式来学习软件设计。

设计模式的类型

序号	模式 & 描述	包括
1	创建型模式 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。	工厂模式（Factory Pattern） 抽象工厂模式（Abstract Factory Pattern） 单例模式（Singleton Pattern） 建造者模式（Builder Pattern） 原型模式（Prototype Pattern）
2	结构型模式 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。	适配器模式（Adapter Pattern） 桥接模式（Bridge Pattern） 过滤器模式（Filter、Criteria Pattern） 组合模式（Composite Pattern） 装饰器模式（Decorator Pattern） 外观模式（Facade Pattern） 享元模式（Flyweight Pattern） 代理模式（Proxy Pattern）
3	行为型模式 这些设计模式特别关注对象之间的通信。	责任链模式（Chain of Responsibility Pattern） 命令模式（Command Pattern） 解释器模式（Interpreter Pattern） 迭代器模式（Iterator Pattern） 中介者模式（Mediator Pattern） 备忘录模式（Memento Pattern） 观察者模式（Observer Pattern） 状态模式（State Pattern） 空对象模式（Null Object Pattern） 策略模式（Strategy Pattern） 模板模式（Template Pattern） 访问者模式（Visitor Pattern）
4	J2EE 模式 这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。	MVC 模式（MVC Pattern） 业务代表模式（Business Delegate Pattern） 组合实体模式（Composite Entity Pattern） 数据访问对象模式（Data Access Object Pattern） 前端控制器模式（Front Controller Pattern） 拦截过滤器模式（Intercepting Filter Pattern） 服务定位器模式（Service Locator Pattern） 传输对象模式（Transfer Object Pattern）


（1）单一职责原则-Single Responsibility Principle-SRP-优化代码的第一步

定义：就一个类而言，应该仅有一个引起它变化的原因。
实际开发：
单一职责所表达出的用意就是”单一“二字。如何划分一个类，一个函数的职责，每个人都有自己的看法，这需要根据个人经验、具体的业务逻辑而定，他也有一些基本的指导原则，例如，两个完全不一样的功能就不应该放在一个类中。一个类中应该是一组相关性很高的函数、数据的封装。工程师可以不断的审视自己的代码，根据具体的业务、功能对类进行相应的拆分，这事程序员优化代码迈出的第一步。

（2）开闭原则-Open Close Principle-OCP-让程序更稳定、更灵活

定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。
实际开发：
开闭原则指导我们，当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。这里的“应该尽量”4个字说明OCP原则并不是说绝对不可以修改原始类的。当我们嗅到原来的代码“腐化气味”时，应该尽早地重构，以便使代码恢复到正常的“进化”过程，而不是通过继承等方式添加新的实现，这会导致类型的膨胀以及历史遗留代码的冗余。我们的开发过程中也没有那么理想化的状况，完全地不用修改原来的代码，因此，在开发过程中需要自己结合具体情况进行考量，是通过修改旧代码还是通过继承使得软件系统更稳定、更灵活，在保证去除“代码腐化”的同时，也保证原有模块的正确性。

（3）里氏替换原则-Liskor Susition Principle-LSP-构建扩展性更好的系统

定义：如果每一个类型为S的对象O1，都有类型为T的对象O2，使得以T定义的所有程序P在所有的对象O1都代换成O2时，程序P的行为没有发生变化，那么类型S就是类型T的自类型。
定义2:所有引用基类的地方必须能透明地使用其子类的对象

说明：
里氏替换的核心原理是抽象，抽象又依赖于继承这个特性，在OOP当中，继承的优缺点都相当明显。优点如下：
1.代码重用，减少创建类的成本，每个子类都拥有父类的方法和属性；
2.子类与父类基本相似，但又与父类有区别；
3.提高代码的可扩展性

缺点：
1.继承是侵入性的，只要继承就必须拥有父类的所有属性和方法；
2.可能造成子类代码冗余、灵活性降低，因为子类必须拥有父类的属性和方法

里氏替换指导我们构建扩展性更好的软件系统

开闭原则和里氏替换是相互依存的，通过里氏替换来达到对扩展的开放，对修改关闭的效果。同时强调了OOP的重要特性-抽象，在开发过程中抽象是代码优化的重要一步

（4）依赖倒置原则-Dependence Inversion Principle-DIP-让项目拥有变化的能力

定义：依赖倒置原则指代了一种特定的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了。
几个关键点：
1.高层模块不应该依赖低层模块，两者都应该依赖于抽象；
2.抽象不应该依赖于细节；
3.细节应该依赖于抽象。

模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口和抽象类产生的。

面向接口编程，面向抽象编程

（5）接口隔离原则-InterfaceSegregation Principles-ISP-系统有更高的灵活性

定义：客户端不应该依赖于它不需要的接口
定义2:类间的依赖关系应该建立在最小接口上

Rob（Robert C Martin）将单一职责、开闭原则、里氏替换、接口隔离以及依赖倒置（依赖反转）五个原则定义为SOLID原则。

SOLID是测试驱动开发、敏捷开发以及自适应软件开发基本原则的重要组成部分

（6）迪米特原则-Law of Demeter-LOD（最少知识原则-Least Knowledge Principle）-更好的扩展性

定义：一个对象应该对其他对象有最少的了解。

（7）合成复用原则（Composite Reuse Principle）

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

总结

在应用开发注程中，最难的不是完成应用的开发工作，而是在后续的升级、维护过程中让应用系统能够柳抱变化。拥抱变化也就意味看在满足需求且不破坏系统稳定性的前提下保持高可扩展性。高内聚，低耦合，在经历了各版本的变更之后依然保持清晰，灵活，稳定的系统架构。当然，这是一个比较理想的情况，但我们必须要朗着这个方向去努力，那么遵循面向对象六大原则就是我们走向灵活软件之路所迈出的第一步。

结束语

接下里就是设计模式的文章啦！