初识设计模式

前段时间因为在软件考试中涉及到一些设计模式相关的知识，今天就来说说一个小白对于设计模式的认识。

对于设计模式，在我看来就是一些优秀的开发方法的总结，使自己编写的程序更加符合软件工程的设计思想。

（一）设计模式的分类:创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。当然，我们还会讨论另一类设计模式：J2EE 设计模式。

 

（二）设计模式具体的分类：

序号

模式 & 描述

包括

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）

（三）设计模式的六大原则：

①开关原则：

问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

一个软件实体（如类，模块，和函数）应该对扩展开放，对修改关闭模块应该对外延具有开放性，对修改具有封闭性。采用一种无需对构件自身内部（代码或内部逻辑）做修改，就可以进行扩展（在构件所确定的功能域内）的方式来说明构件。

②Liskov替换原则

问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。只要父类能出现的地方，其子类就应该能出现。也就是用子类替换父类后，保证程序照样运行。

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能,否则可能导致原来的功能出错。

在任何父类出现的地方都可以用它的子类来替换，而不影响功能。能够保证系统具有良好的拓展性，同时基于类的多态性，能够减少代码冗余，避免运行期的类型判别。

③依赖倒置原则

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在 java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任 务交给他们的实现类去完成。         

依赖倒置原则的核心思想是面向接口编程

依赖于抽象。高层模块不依赖于底层具体模块，二者都依赖于抽象。当两个模块之间存在紧密的耦合关系时，最好的方法就是分离接口和实现：在依赖之间定义一个抽象的接口使得高层模块调用接口，而底层模块实现接口的定义

④单一职责原则

问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

系统中的每一个类都应该只有一个职责（不是一个方法），如果多个职责耦合在一起，会影响复用性。单一职责原则体现了“高内聚，低耦合”

⑤接口分离原则

问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则

接口细化，也就是接口中的方法要尽量少。

采用多个与特定顾客类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。客户端不应该依赖那些它不需要的接口。

⑥迪米特法则

问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

解决方案：尽量降低类与类之间的耦合。

又叫作最少知道原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

我个人理解就是像java中封装原则，使软件具有高内聚低耦合的特性。