设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。
如果一个问题反复发生,那么这个问题的解决方案就会被有效使用,这种被频繁使用的解决方案就叫做模式。设计模式是语言独立(开发语言)的,主要用来解决面向对象设计的一般问题。当你设计一种方案,你应该知道一些常见的解决方案的名称。通过学习设计模式,对于有效沟通也大有裨益。实际上,你可能已经很熟悉一些设计模式了,只是没有一个众所周知的名称来描述而已。
模式起源于建筑领域,毕竟与只有几十年历史的软件工程相比,已经拥有几千年沉淀的建筑工程有太多值得学习和借鉴的地方。Christopher Alexander博士——模式之父(The father of patterns)及其研究团队用了约20年的时间,对住宅和周边环境进行了大量的调查研究和资料收集工作,发现人们对舒适住宅和城市环境存在一些共同的认同规律,Christopher Alexander在著作A Pattern Language: Towns, Buildings, Construction中把这些认同规律归纳为253个模式,对每一个模式(Pattern)都从Context(前提条件)、Theme或Problem(目标问题)、 Solution(解决方案)三个方面进行了描述,并给出了从用户需求分析到建筑环境结构设计直至经典实例的过程模型。在Christopher Alexander的另一部经典著作《建筑的永恒之道》中,他给出了关于模式的定义:
每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心,通过这种方式,我们可以无数次地重用那些已有的成功的解决方案,无须再重复相同的工作。
简单地用一句话表示:
模式是在特定环境下人们解决某类重复出现问题的一套成功或有效的解决方案。【A pattern is a successful or efficient solution to a recurring problem within a context】.
1990年,软件工程界开始关注ChristopherAlexander等在这一住宅、公共建筑与城市规划领域的重大突破。最早将模式的思想引入软件工程方法学的是1991-1992年以“四人组(Gang of Four,简称GoF,分别是Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides)”自称的四位著名软件工程学者,他们在1994年归纳发表了23种在软件开发中使用频率较高的设计模式,旨在用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟。
GoF将模式的概念引入软件工程领域,这标志着软件模式的诞生。软件模式(Software Patterns)是将模式的一般概念应用于软件开发领域,即软件开发的总体指导思路或参照样板。软件模式并非仅限于设计模式,还包括架构模式、分析模式和过程模式等,实际上,在软件开发生命周期的每一个阶段都存在着一些被认同的模式。
软件模式与具体的应用领域无关,也就是说无论你从事的是移动应用开发、桌面应用开发、Web应用开发还是嵌入式软件的开发,都可以使用软件模式。
在软件模式中,设计模式是研究最为深入的分支,设计模式用于在特定的条件下为一些重复出现的软件设计问题提供合理的、有效的解决方案,它融合了众多专家的设计经验,已经在成千上万的软件中得以应用。 1995年, GoF将收集和整理好的23种设计模式汇编成Design Patterns: Elements of Reusable Object-Oriented Software【《设计模式:可复用面向对象软件的基础》】一书,该书的出版也标志着设计模式正式成为面向对象(Object Oriented)软件工程的一个重要研究分支。
一般而言,一个模式有四个要素组成:
效果(Consequence):描述了模式应用的效果及使用模式应该权衡的问题,比如对系统的扩充性、可移植性的影响。影响也包括负面的影响。
虽然GoF设计模式只有23个,但是它们各具特色,每个模式都为某一个可重复的设计问题提供了一套解决方案。根据它们的用途,设计模式可分为创建型(Creational),结构型(Structural)和行为型(Behavioral)三种,其中创建型模式主要用于描述如何创建对象,结构型模式主要用于描述如何实现类或对象的组合,行为型模式主要用于描述类或对象怎样交互以及怎样分配职责,在GoF 23种设计模式中包含5种创建型设计模式、7种结构型设计模式和11种行为型设计模式。此外,根据某个模式主要是用于处理类之间的关系还是对象之间的关系,设计模式还可以分为类模式和对象模式。我们经常将两种分类方式结合使用,如单例模式是对象创建型模式,模板方法模式是类行为型模式。
值得一提的是,有一个设计模式虽然不属于GoF 23种设计模式,但一般在介绍设计模式时都会对它进行说明,它就是简单工厂模式,也许是太“简单”了,GoF并没有把它写到那本经典著作中,不过现在大部分的设计模式书籍都会对它进行专门的介绍。
常用24中设计模式及其学习难度和视频频率如下表:
类型 | 模式名称 | 学习难度 | 使用频率 |
---|---|---|---|
创建型模式 Creational Pattern |
单例模式 Singleton Pattern |
★☆☆☆☆ | ★★★★☆ |
简单工厂模式 Simple Factory Pattern |
★★☆☆☆ | ★★★☆☆ | |
工厂方法模式 Abstract Factory Pattern |
★★★★☆ | ★★★★★ | |
抽象工厂模式 Abstract Factory Pattern |
★★★★☆ | ★★★★★ | |
原型模式 Prototype Pattern |
★★★☆☆ | ★★★☆☆ | |
建造者模式 Builder Pattern |
★★★★☆ | ★★☆☆☆ | |
结构型模式 Structural Pattern |
适配器模式 Adapter Pattern |
★★☆☆☆ | ★★★★☆ |
桥接模式 Bridge Pattern |
★★★☆☆ | ★★★☆☆ | |
组合模式 Composite Pattern |
★★★☆☆ | ★★★★☆ | |
装饰模式 Builder Pattern |
★★★☆☆ | ★★★☆☆ | |
外观模式 Fa?ade Pattern |
★☆☆☆☆ | ★★★★★ | |
享元模式 Flyweight Pattern |
★★★★☆ | ★☆☆☆☆ | |
代理模式 Proxy Pattern |
★★★☆☆ | ★★★★☆ | |
行为型模式 Behavioral Pattern |
职责链模式 Chain of Responsibility Pattern |
★★★☆☆ | ★★☆☆☆ |
命令模式 Command Pattern |
★★★☆☆ | ★★★★☆ | |
解释器模式 Interpreter Pattern |
★★★★★ | ★★★★☆ | |
迭代器模式 Iterator Pattern |
★★★☆☆ | ★★★★★ | |
中介者模式 Mediator Pattern |
★★★☆☆ | ★★☆☆☆ | |
备忘录模式 Memento Pattern |
★★☆☆☆ | ★★☆☆☆ | |
观察者模式 Observer Pattern |
★★★☆☆ | ★★★★★ | |
状态模式 State Pattern |
★★★☆☆ | ★★★☆☆ | |
策略模式 Strategy Pattern |
★☆☆☆☆ | ★★★★☆ | |
模板方法模式 Template Method Pattern |
★★☆☆☆ | ★★★☆☆ | |
访问者模式 Proxy Pattern |
★★★★☆ | ★☆☆☆☆ |
对于面向对象软件系统的设计而言,在支持可维护性的同时,提高系统的可复用性是一个至关重要的问题,如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一。在面向对象设计中,可维护性的复用是以设计原则为基础的。每一个原则都蕴含一些面向对象设计的思想,可以从不同的角度提升一个软件结构的设计水平。
面向对象设计原则为支持可维护性复用而诞生,这些原则蕴含在很多设计模式中,它们是从许多设计方案中总结出的指导性原则。面向对象设计原则也是我们用于评价一个设计模式的使用效果的重要指标之一,在设计模式的学习中,大家经常会看到诸如“XXX模式符合XXX原则”、“XXX模式违反了XXX原则”这样的语句。
最常见的6种面向对象设计原则如下表所示:
设计原则名称 | 简称 | 定义 | 使用频率 |
---|---|---|---|
单一职责原则 Single Responsibility Principle |
SRP | 一个类只负责一个功能领域中的相应职责 | ★★★★☆ |
开闭原则 Open-Closed Principle |
OCP | 软件实体应对扩展开放,而对修改关闭 | ★★★★★ |
里氏代换原则 Liskov Substitution Principle |
LPS | 所有引用基类对象的地方能够透明地使用其子类的对象 | ★★★★★ |
依赖倒转原则 Dependence Inversion Principle |
DIP | 抽象不应该依赖于细节,细节应该依赖于抽象 | ★★★★★ |
接口隔离原则 Interface Segregation Principle |
ISP | 使用多个专门的接口,而不使用单一的总接口 | ★★☆☆☆ |
迪米特法则 Law of Demeter |
LoD | 一个软件实体应当尽可能少地与其他实体发生相互作用 | ★★★☆☆ |
原文地址:http://blog.csdn.net/thinkercode/article/details/46352607