设计模式(1)——简介(翻译自维基百科wiki)

说明(Tips)

翻译维基百科对于设计模式的相关描述。后续会有对23中设计模式的实践。
表格内容处正在更新中(暂时只更新23个设计模式内容)

此文章主要内容:

  1. 设计模式发展历史
  2. 设计模式学习的价值所在
  3. 书籍推荐。在“发展历史(History)”章节最后,有学习设计模式的经典教材。其中在“文档(Document)”章节介绍了经典书籍《设计模式》的组织结构,相信对于《设计模式》的学习框架有一个整体的了解。

概述(Header summary)

在软件工程领域,设计模式:是对给定软件设计需求情况下的一种通常的,可复用的解决方案。然而它并不是一种能直接转化成源代码或者机器代码的设计,而是一种能够应用在许多不同情境下的解决问题的模板描述。对程序员来说,当他们在设计一个应用或者系统时,设计模式是一种解决一般性问题的形式化的最佳实践。

面向对象设计模式在不需要指定与最终应用程序相关的类与对象的情况下,经典地展示出类与对象之间的关系与交互。需要注意的是:那些隐含易变状态的设计模式很可能不适用于函数式编程语言;某些语言使用特定的设计模式可能显得没有必要,因为这些语言可能已经内置了对特定设计模式解决问题的方案;面向对象的设计模式不见得适用于非面向对象的程序设计语言。

设计模式可被视为一种结构化的计算机编程桥梁,此桥梁连接编程范式与具体算法。

发展历史(History)

模式起源于 Christopher Alexandert提出的建筑学概念。 在 1987年, Kent Beck 和Ward Cunningham开始在编程上试验一些模式——模式语言,并且在那年的OOPSLA(Object-Oriented Programming, Systems, Languages & Applications)会议上展示了他们的成果。在接下来的数年里,Beck, Cunningham还有许多科学家相继开始这方面的研究。

在1994年 的《Design Patterns: Elements of Reusable Object-Oriented Software》(设计模式:可复用面向对象软件的基础)这本书被出版后,设计模式在计算机科学领域广为流传。这本书的作者们被称为“Gang of Four”(四人帮),通常我们简写为”GoF“。同一年,首届“ Pattern Languages of Programming Conference”会议召开。接下来的一年,“Portland Pattern Repository ”(波兰模式库)——为设计模式文档而建立的文档库建立了。

有关设计模式的著名书籍如下(注:点击链接为国内版本,划线代表国内没出版):

虽然设计模式已经被实践应用很长时间了,但是有关设计模式概念的形式化多年来仍然没有很大进展。

实践(Practice)

设计模式通过提供久经考验且被证实的开发范式加速开发进程。有效的软件设计需要考虑那些在代码实现时才可能显现的一些问题。刚完成的代码常常隐藏着细小的问题,这些问题可能需要花些日子才能被检测到并且这些问题常常会导致程序出现重大问题(bug)。复用设计模式能预防这样的问题并且给程序员和架构师提升了代码的可读性。

为了实现灵活性,设计模式通常会引入额外的中间构建物,这种情况可能会导致最终设计变得复杂,降低程序的性能。

按照定义,一个模式必须通过再编程的方式进入程序代码中。由于一些作者将此视为从由组建提供的软件重用向后退一步,研究者就努力将模式转化为组件。 Meyer 和Arnout就曾提供了2/3设计模式的完整或者部分的组件。

软件设计技术很难应用到覆盖范围很广的问题上。它只提供一种普遍的,具有一般性地解决方案,并且以形式记录下来,这种形式不指定在特定问题上的特定细节。

模式分类与列表(Classification and list)

设计模式最初被分为三类:creational patterns(创建型), structural patterns(结构型),behavioral patterns(结构型),并且使用 delegation(委托), aggregation(聚合), consultation(协商)等概念加以描述。对于面向对象设计,有 coupling(耦合) ,cohesion(内聚), inheritance(继承), interface(接口), polymorphism(多态)等概念。
另一个分类方法引入了架构设计模式( architectural design pattern)的概念,它可能会被应用到软件架构级别,例如 MVC(Model–View–Controller)模型。

创建型(Creational patterns)

注:“In Design Patterns”表示 《设计模式》是否涵盖此模式内容,同理“In Code Complete”
	表示《代码大全》。Other代表其它文献。
	点击相应的链接,可以查看相应书籍的豆瓣介绍。
名称 描述 In Design Patterns In Code Complete Other
抽象工厂
Abstract factory
提供一个接口用来创建一系列相关或者独立的对象但并不制定他们的具体类 Yes Yes N/A
工厂方法
Factory method
定义一个接口用来创建一个单一对象,但是由子类决定哪个类将被初始化。工厂方法让一个类推迟初始化任务给子类。. Yes Yes N/A
建造者
Builder
.隔离一个复杂对象的构造与表现,允许同一构造器创建多样的表现。 Yes No N/A
单例
Singleton
确保一个类只能被初始化一次,并对外提供一个统一的访问点来获取这个实例。 Yes Yes N/A
原型
Prototype
指定使用原型实例创建的对象的种类,并从现有对象的“骨架”创建新对象,从而提高性能并将内存占用量保持在最小值。 Yes No N/A
依赖注入
Dependency Injection
.
延迟初始化
Lazy initialization
. PoEAA
多例
Multiton
.
对象池
Object Pool
.
资源获取即初始化
Resource acquisition
is initialization (RAII)
.

结构型(Structural patterns)

名称 描述 In Design Patterns In Code Complete Other
外观
Facade
为一个子系统中的一系列接口对外提供统一的接口。外观模式提供让子系统更易使用的更高层次的接口 Yes Yes N/A
装饰器
Decorator
动态附加额外的职责给对象以保持相同的接口。装饰器对子类继承功能来说提供灵活了的可选方案。 Yes Yes N/A
适配器、包装器或翻译器
Adapter, Wrapper, or Translator
将一个类的接口转化成客户端所期待的其它接口。适配器让本不兼容的类一起协同工作。企业整合模式等同于译者(translator) Yes Yes N/A
享元
Flyweight
利用共享有效地支持大量类似的对象 Yes No N/A
组合
Composite
将对象组合成树形结构来表示部分与整体的层级继承关系。能让客户端统一的看待单独的对象和由这些对象组成的组建 Yes Yes N/A
桥接
bridge
从类的实现上解耦出一个抽象,让两者单独变化 Yes Yes N/A
代理
Proxy
为控制访问类的对象提供一个代理,或者说占位 Yes No N/A
扩展对象
Extension object
添加功能到某个层级而不影响层级的继承关系 No No 敏捷软件开发
前端控制器
Front controller
此模式跟web开发相关。它提供一个处理请求的集中入口。 No No J2EE核心模式企业应用架构模式
标记
Marker
与类的元数据相关联的空接口 No No Effective java
模块
Module
组合若干个相关联的元素形成单一的实体类。相关联的元素例举:classes,singletons,methods等 No No N/A
孪生兄弟
Twin
对于不支持多继承的编程语言来说,Twin提供了允许多继承的解决方案 No No N/A

行为型(Behavioral patterns)

并发型(Concurrency patterns)

文档(Document)

设计模式的文档描述了模式被应用的上下文,模式解决上下文中的冲突,还有推荐的解决方案。没有单一或者标准的形式来记录设计模式。当然,有许多的格式被不同的模式作者使用。然而,Martin Fowler——一种非常著名的模式形式已经成为公认的新模式的写作首要考虑的形式。
GoF的文档格式就是一个例子:

  • 模式名与分类(Pattern Name and Classification): A descriptive and unique name that helps in identifying and referring to the pattern.
  • 目的(Intent): A description of the goal behind the pattern and the reason for using it.
  • 已知的(Also Known As): Other names for the pattern.
  • 动机(Motivation (Forces) ): A scenario consisting of a problem and a context in which this pattern can be used.
  • 适用性(Applicability): Situations in which this pattern is usable; the context for the pattern.
  • (结构)Structure: A graphical representation of the pattern. Class diagrams and Interaction diagrams may be used for this purpose.
  • (参与者)Participants: A listing of the classes and objects used in the pattern and their roles in the design.
  • (协作)Collaboration: A description of how classes and objects used in the pattern interact with each other.
  • (结果)Consequences: A description of the results, side effects, and trade offs caused by using the pattern.
  • (实现)Implementation: A description of an implementation of the pattern; the solution part of the pattern.
  • (样例代码)Sample Code: An illustration of how the pattern can be used in a programming language.
  • (应用场景)Known Uses: Examples of real usages of the pattern.
  • (相关模式)Related Patterns: Other patterns that have some relationship with the pattern; discussion of the differences between the pattern and similar patterns.

批评(Criticism)

我们注意到,设计模式可能仅仅只是一些编程语言(Java,C++等)所缺少的特性的标志。 Peter Norvig证明了Design Patterns书中23个设计模式中的16个 在Lisp 或者 Dylan语言中都被简化了或者被淘汰了,因为这些语言直接支持了这些模式。Hannemann 和Kiczales使用面向切面编程语言( aspect-oriented programming language (AspectJ) )实现了23个设计模式中的若干个,他们做出的相关观察结果展示了代码层的依赖从23个设计模式中的17个实现中移除了,并且面向接口编程能简化设计模式的实现。如果有兴趣可以看看Paul Graham对于此话题讨论文章

猜你喜欢

转载自blog.csdn.net/qq_37206105/article/details/84031970
今日推荐