Design Patterns Explained , 设计模式和算法的共同点

        这两天看完了<<Design Patterns Explained>>, 大开眼界,书中推崇的"基于模式"的软件设计方法一反传统软件设计的思维.以前,甚至现在手上那本教科书所描述的都是按照需求,提取名词,抽象共同点,寻找动词,找出关系,封装子系统等等.......从局部到整体,而<<Design Patterns Explained>>所描述的却是基于模式,从全局着手,寻找最高模式,然后引出其他的模式,对需求从最简单的描述一步一步添加信息另他复杂化,而模式就在这些慢慢复杂化的场景信息中,寻找变化点,一次封装仅仅封装一个变化点.

        基于模式的思考方式去设计软件很象基于算法的思考方式去解答ACM的题目.以前做ACM题目,抽象了问题模型后,会匹配那种算法合适模型的主要问题,然后局部采用什么什么算法,找到算法后,会考虑在要求的数据量,时间和空间范围内,是否能够解答问题,如果不能则对算法作出优化.有时候你并不需要去了解算法的细节,或许3个月后,你不会写任何的算法,但是你知道那个算法的时间和空间复杂度和在那种场景下可以运用,而且可以作出那种类型的优化,对于算法设计这已经够了,等到要用的时候,找出以前写的模版,套一下,改改就搞定了.而<<Design Patterns Explained>>所描述的软件设计方法跟这样的算法设计思路也是非常相象.或许你并不知道该设计模式的细节,但是你知道该设计模式所要解决的问题和可以运用的场景,这已经足够了.

       或许,从另外一个角度看,设计模式和算法,本质上都是解决问题的方案,只是前者的问题域是在软件设计上,后者的问题域是在真实的问题上.

      看来世间万物变化虽大,但是很多变化背后都有本质上的一致.把以前陈旧的思想应用到其他的问题空间中,或许又会演变出全新的理论出来.

模式的情景:

Bridge Pattern:为了分离抽象的变化点和实现的变化点,使他们分别独立发展

Adapter Pattern:为旧的接口适配新的接口

Facade Pattern:给客户提供简单的接口,隐藏系统的复杂性

Abstract Factory Pattern:提供创建一系列对象的共同的抽象接口,至于那一系列,可以根据配置选择(可以是根据配置文件+Switch或者硬编码让用户选择等方法,看使用的场景了)

Strategy Pattern:封装解决某一问题的策略接口,至于实现,留给后人吧.

Decorator Pattern:对于要被装饰的对象,可以提供不确定顺序的装饰功能.至于那种顺序,也是根据配置吧,这个可以结合抽象工厂模式使用...........这模式责任链是个例子(<<Core j2EE Patterns>>).

Singleton Pattern:顾名思义,使得你的类只实例一个对象.注意:在多线程环境下,记得synchronized

Observer Pattern:对变化的一系列观察者的封装,所有观察者提供统一的接口.所以,如果你的系统观察者是显然的那几个,而且未来也不会变化或许变化不大的话,不要使用这模式,不然会增加程序的复杂性,变化点是观察者

Template Pattern:跟语言本身提供的template是同一个思想,抽象出解决问题的算法,至于算法细节的对象,也是留给要使用此算法的人在实例化的时候确定吧.共同点是算法框架,变化点是算法细节所使用的对象

Factory Method Pattern:提供一个抽象方法,把某抽象出的算法框架所使用的某些对象的选择权留给派生此类的后人.跟Template Pattern一样,共同点是算法框架,变化点是使用的对象,对变化的对象提供统一的实例化方法,隐藏对象的选择.

在此书的第2版还有个Object Pool Pattern,跟其他的连接池和线程池所解决的问题都是一样,管理某些资源,减少大量重复创建和销毁的时间,在网上看了一个人的实现,用遍历去寻找他需要的对象..........汗,当数据量大的时候,这个模式也就失去了意义了.......所以在使用此模式的时候还需要优化内部实现的算法细节,AVL是个不错的选择,高度平衡,数据量大的时候也就是logn的时间复杂度.

      两天看完了这本书,现在又噼里啪啦地说了一大堆.................不知道现在的我进入了设计模式的大门没有呢?