关于设计模式的思考

         工作这么多年,经常遇到关于设计模式的思考,这也是很多面试官最爱问的问题之一.也有很多著名的书籍专门论述它们,并且一一起了名字和给出示例场景.下面是摘自百度百科的23条设计模式:

       

设计模式分为三种类型，共23类。

创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。

结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。

行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式、访问者模式。

按alphabeta排列简介如下。

Abstract Factory（抽象工厂模式）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

Adapter（适配器模式）：将一个类的接口转换成客户希望的另外一个接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

Bridge（桥接模式）：将抽象部分与它的实现部分分离，使它们都可以独立地变化。

Builder（建造者模式）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

Chain of Responsibility（职责链模式）：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。

Command（命令模式）：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。

Composite(组合模式)：将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。

Decorator(装饰模式)：动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。

Facade（外观模式）：为子系统中的一组接口提供一个一致的界面， F a c a d e模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

Factory Method(工厂模式)：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。

Flyweight（享元模式）：运用共享技术有效地支持大量细粒度的对象。

Interpreter（解析器模式）：给定一个语言, 定义它的文法的一种表示，并定义一个解释器, 该解释器使用该表示来解释语言中的句子。

Iterator（迭代器模式）：提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。

Mediator（中介模式）：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

Memento（备忘录模式）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。

Observer（观察者模式）：定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。

Prototype（原型模式）：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。

Proxy（代理模式）：为其他对象提供一个代理以控制对这个对象的访问^[1]。

Singleton（单例模式）：保证一个类仅有一个实例，并提供一个访问它的全局访问点。

State（状态模式）：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。

Strategy（策略模式）：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。

Template Method（模板方法模式）：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

Visitor（访问者模式）：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

这些模式我们在开发中或多或少都用到过,不管是有意的还是无意的,只不过当时没有这么系统的起名字研究.前人的经验当然必须要借鉴,但也不能生搬硬套。当一个程序员写的代码多了, 自然会有很多总结经验和感悟.反之如果没有太多的实践,只是为了套用模式去写代码,就会觉得诸多掣肘。下面谈一下我个人的一些看法.

首先,设计模式是独立于开发语言的.它为某种语言平台之下开发某些功能代码提供基本的思路组织接口逻辑流程等等.基本上在各个语言之中都可以采用相同的设计模式,而不是说专用于某个语言。当然有些语言可能特别适合某种模式的实现,某些语言可能不适合。所以,用好设计模式的前提还是你对该语言的基本特性或高级特性非常清楚,这些只有通过大量的实践代码才能达到,这又回到开始的问题理论需要从实践中来。如果已经有一些先辈制作了很多框架,拿来套,只要理解了其设计本质,那应用起来就比较简单,即使是你不熟悉的语言或是代码,也可以很快上手,照葫芦画瓢总比平地盖房子简单的多, 这就是应用框架的力量.

其次, 程序开发是一门艺术,不应该被设计模式所限制.设计模式是一种编程思路,它最终要靠具体的代码去实现, 去反映.如果写代码的时候一直在思考着有没有用到这个模式,是不是完全遵守这个规范,那你就得要被一大堆的名词术语所淹没,书写代码的流程也会经常被打断.有些时候简单的代码反而会被大大复杂化,因为你的代码根本用不到那么多的特性,或者说你所使用的语言根本很难实现这模式。所以,我还是主张自由的写代码吧,设计模式的问题留到详细设计阶段去解决,写代码之前先多花点时间做个详细设计,哪怕仅仅是脑海中的"设计".

再次,应用设计模式的好处.

1. 设计模式可以或者应该解决的问题是良好的扩展性,维护性。你所写出来的代码是不是能够易于理解,能够迅速根据业务需求增加新功能而不会或很少影响原有功能.这是评价一个系统可维护性的重要指标。应用设计模式一般会提供一个良好的框架约束,让后来者都按照这个模式添加代码,共性被抽离出来了,限制了后来的代码随意发挥,自然可维护性就强了.

2. 设计模式不能解决的问题是代码质量。应用一个好的设计模式,并不一定能够编写出来优秀的代码。框架只能限制总体的流程,具体的细节还得要靠程序员自己的发挥,需要哪些if else,需要应用什么算法数据结构,效率如何,是否有出错处理等等,这些问题才是决定最后的产品质量的根本.有些时候为了达到既定的执行效率可能还会牺牲一些良好的设计风格,采用一些语言层面的奇技淫巧,搞出一些晦涩难懂的接口。所以有时候设计模式和开发还会产生矛盾,优雅漂亮的设计通常都会带来一些执行流程上的额外开销,当然大多数情况下这些都是可以忽略不计的。所以开发一个产品的时候,好的设计师固然重要,优秀的程序员也同等重要,当然优秀的设计师一般自身都是优秀的程序员.

最后 ,按照个人的理解总结一下基本的设计理念吧

a.  抽象,封装.  尽量暴露方法而不是数据。每种编程语言总会有数据类型有函数(方法)调用,封装接口的时候导出一个动作被别人调用,总是比导出一个数据结构如c里面的struct 容易理解.数据结构太宽泛了,又不稳定。尤其是越高层的接口,越应该这么做,越高层暴露的接口越少,越底层越多,形成一个金字塔式的结构,而不要是平面的结构。自顶向下的设计,自底向上的实现.这有点像老生常谈,但确实是最基本最重要的设计理念。

b. 面向对象VS面向过程. 传统的编程方法是面向过程,程序由一个一个的函数调用组成;事实证明OO(面向对象)设计方法更容易理解,更容易构建大型的系统。所以现代很多语言,都提供了oo支持,如php,js,lua,c++等。整个系统由若干个对象组成,各个对象之间暴露一定的方法进行交互。微软的COM设计理念很好的诠释了这一点,抛开一些复杂的进程线程模型,IUnKnow的三个接口为我们提供了无限扩展性的对象接口实现, AddRef Release实现了引用计数,这在c++语言中是很重要的一点,其他基于内存自动分配回收机制的则不需要关注这一点,如java,js,php,lua等,但很多垃圾回收机制本身都是基于引用计数实现的,如php,lua等。QueryInterface接口则用来根据一个guid查询支持的其他接口,所以接口都由IUnKnow派生而来。不是说就不能面向过程,某些细节过程,比较独立的功能面向过程会更适合,它们不需要更多的扩展性,没有那么多变化.比如一个计算md5,计算base64编码的函数完全可以只用一个函数导出供使用.(windows所有的api都是面向过程的,linux基本的系统调用也没有使用类的方式封装).在c++面向对象的类设计中,一般接口(暴露的方法集合)都是纯虚函数,其他语言也有类似的概念,这又印证了上一个原则抽象,封装。

c.复用。 好的设计模式能够简化代码,把很多看似不同的业务逻辑抽象封装成统一的接口来调用,更上层可以用统一的代码来处理,下层可以有不同的实现.譬如说你的系统里用到了很多不同的第三方库,接口各异,没关系,你可以提供一个中间适配层,把他们都有机的串联起来,使得调用者体会不到具体的实现,看到的仍然是统一的接口.微软的odbc,java的jdbc都是这方面的例子。继承是由语言提供的一种代码级别的复用,父类提供大部分功能,子类可以定制自己的实现,重写或者复用。实现功能时,组合比继承能带来更好的封装性,扩展性。例如已经有一个组件A的类定义CA,它提供了一个接口IA供调用。现在在设计组件B,可以复用组件A,它可以从CA继承,也可以有一个数据成员引用一个IA接口.如果是继承则组件B和A的关系就近了,通常它们必须是同一个模块,而组合则不需要,能达到二进制级别的复用。所以导出类给别人使用(继承)不如只导出一个只包含方法的接口(组合)带来更好的独立性。二进制级别的复用总是比代码级的复用带来更高的封装性,独立性,dll(so)比lib(a)更独立,动态的链接比静态链接库更灵活。当然,更独立带来的问题是你要修改它原来的行为将会变的很困难,除非他预先留了一些回调接口。所以,dll尽量不要导出类,可以导出接口(接口在语法上也是一个特殊的类,但设计目的不同).最理想的设计是动态装载一个dll(so),注册其中提供的组件,然后就可以在它提供的接口中任意调用.就像windows的com的dll,只有一个DllRegisterServer类似的函数, 剩下的就全部通过接口头文件定义了.php的扩展机制也与此类似。运行期复用总是比编译期复用更简单,更好维护。一个简单的例子是配置文件,二进制代码不需要更改,一些核心的设置参数可以由配置文件来决定。这样就使得程序维护交给一个并不懂程序的人成为了可能, 他只要会用记事本打开一个文本文件编辑或打开一个网页做一些选择题或填空题。所以大型软件的配置文件总是很复杂,如mysql,apache等等,但这并不妨碍它们的流行度。

d. 接口参数灵活,善用约定。 在一个软件设计中总免不了会有很多组件,每个组件会提供一些接口,而接口其实又是一组函数调用的集合.归根结底,最基本的接口单位还是函数,这点不论哪一种语言都是这样的。每个函数完成一定的功能,这点没什么好说的,参数设计上也很重要,我的经验是参数首先数据类型上最好是简单的类型,可以包括基本的数据类型,也可以是别的组件的一个实例(纯虚接口),最好要有扩展性的参数。这和编程语言息息相关,脚本型的通常语言已经内置了这种扩展性.如 js中的Object, 它本身就可以包含任意层次的数据,比如说要设计一个接口函数 void func(int  id, Object  r);在没有第二个参数之前,它就只能接收一个整数做id, 以后要加别的参数,没办法, 必须要换接口。而如果多了一个Object类型的参数,它理论上就变成了一个万能接口, r可以包含任意多的数据,以后要扩展功能,只需对新增的参数做约定即可,不需要增加接口.这就是用参数约定来增加扩展性。当然不能盲目的把接口全部用这种约定和在一起变成一个接口,那样就使得接口混乱了,善用约定可以让你的接口稳定性更强。c++中不存在这样的万能数据类型,但这不是问题,可以自己写一个组件,以纯虚接口的形式做这个参数。其实xml,json本质上都能分层的表示任意层次结构的数据,它们设计初衷也是能够方便的与纯文本(字符串)相互转化,字符串基本是编程语言提供的基本数据类型了。所以上面的接口在c++中可以变成void func(int id,string r).r当然具有无限扩展性了,只不过每次要进行这种转换会损失效率,解决的方法当然有,不过它不在此文讨论范畴。

e. 基于数据流的设计。 mvc是经常被谈论的框架设计模式,也有很多成熟的大型产品商用.其实我觉得它反映的一个基本思想还是基于数据流驱动的分层设计。现在绝大多数软件系统的设计都或多或少要存取用户数据,互联网产品更是如此。所以一个软件系统基本上都可以抽象成 输入, 处理或(存储), 输出(展示给用户)。在这三个步骤中,第二个步骤是根本,尤以产生或存储的数据为最重要。第一和第三个步骤是和用户交互的人机界面,直接决定了用户的体验。数据处理或存储通常是稳定的,比如做一个邮件客户端,经过了多少年用的还是MIME的消息格式文本,用的还是pop3,smtp,imap等协议。再比如说对于一个提供动态内容服务的web站点, 输入就是http post或者get的各种参数,存储的数据是web站点核心业务的数据格式,输出就是html+js+css的一种视觉效果(用文本来描述).输入和输出即人机交互通常多变,要求适应性比较强,而数据处理存储部分通常比较稳定,你可能直接按字段放入一个数据库表就可以了。所以首先按逻辑和UI分是合理和必要的,其次对于输入很复杂的情况就需要一个调度程序根据不同的情况调用不同的模块处理,这就是控制器了。不同的模块各司其职,都由最擅长的人去开发。

最后 ,总结一下,我觉得设计模式就是为了提高软件系统的可扩展性可维护性而在编程层面上的一种设计思路,它最基本的思想就是抽象封装复用,面向对象的设计能更好的达到这一目的(不是唯一的),接口的灵活性扩展性很重要,基于数据流的设计通常能带来更清晰的模块划分,有利于大型项目构建,分工合作，要保持简单的设计理念。没有万能的设计,在一定阶段随业务特点只有最适合的设计,因为只有算法和数据结构基本可以看做是恒定不变的,其他的东西都有可能会变化,好的设计可以使变化的成本降到最低。