设计模式学习历程

今天突发奇想,在道上开个贴,记录各道友学习设计模式的历程、心得。好了,话不多说,我先来说说最近学习的proxy、decorator、adapter、bridge等模式:
为什么会先提这几个呢?
这几个模式,单从uml图或者代码结构看来,两两相似。特别是proxy与decorator很多人都混了,包括我。于是我得出自己的结论:学习模式不只是停留在看懂代码,而是懂其意,也就是老师总提的道。
首先看看proxy与decorator,看了很多关于他们的介绍,虽然从字面上看区别了。但一直不能区分出他们在代码上的区别。直到最近想到了个很生动的例子:演员与替身演员。演员就是decorator,换了套衣服、换了外表就成新角色,还自始至终都是他本人;替身演员则是proxy,真正的演员不来做这些表演,由替身演员来完成。这样的理解,很快我能从概念与应用中区分开他们的用法了。
接下来,我们谈谈adapter与bridge,这两者不像proxy与decorator那么相似,但是也有几分相似。adapter是把两个不相关的类关联起来,通过适配者把被适配者给关联进来;而bridge是把对象抽象出其静态的共公部分与行为相分离,通过行为部分被关联到抽象的实例中。这个抽象的实例看起来很像适配者,而行为看起来很像被适配者,但是adapter模式中的被适配者与要适配出的对象一点关系都没有,bridge模式中的抽象与行为却是有关系的,同属于一个对象。

好了,今天先谈到这里,改天继续学习,继续更新,希望大家能给我更多的意见与建议并也一起参议!

支持 ,帮助大家。分享第一。

谢谢老师的支持,希望更多的道友都能参与进来,一起进步!

呵呵,我觉得那个替身演员的例子不是很恰当。对于Proxy来说,主要目的是为了增加target(被代理对象)的内聚性,但是核心功能还是要被代理对象来完成的,代理对象只是做一些附加的功能。比如权限检查,日志等。
对于装饰器模式,主要是一个过程,是从一个功能单一的小对象到一个批了好多层的大对象。讲究的是功能的动态的组合和添加。就好比您说的一样呵呵。

>>对于Proxy来说,主要目的是为了增加target(被代理对象)的内聚性,但是核心功能还是要被代理对象来完成的,代理对象只是做一些附加的功能。比如权限检查,日志等。

嗯,分析得很在理,当时并没有想到这点,只是看到了代理所做的事。现在听了这位道友的一席话,如梦初醒,谢谢!

很好 ,语言通俗易懂。 不是那么很“专业”,喜欢这种表述。期待更新ing!

从另一个角度能不能这样去理解:
代理在编译阶段扩充功能,而装饰能在运行时期扩充对象的功能?

>代理在编译阶段扩充功能,而装饰能在运行时期扩充对象的功能

模式和语言无关,所以语言的编译和运行和模式无关。

被代理的对象一般是不让client访问的,被装饰的对象client可以访问
代理不送赠品,装饰可能有赠品给了对象。

很多模式表现出一样的外在行为,但是设计出发点不一样,所以模式是一种思维,单单看代码并不足以看出这是哪个模式的实现

使用模式也是为了让代码更具有可读性。

我们经常抱怨别人的代码很难懂,就象说各种语言的人在一起当然很难懂,如果他们都接受基础统一培训和教育,说同一种语言,那么就能够沟通了,设计模式就是程序员编代码的共同语言。

比如我的类名取XXXFactory,你就知道我这里使用工厂,准备创建什么东西,我的类名取XXXProxy,那么你就明白我为XXX使用一个代理类了,如果我们的业务代码都是由这样的以模式命名的基础组件组成,那么我们阅读代码不是更容易,软件不就是人人都可以维护了,这比你用自己的思维编码,使用复杂SQL来代表业务,要易于维护和健壮吧,我想任何一个只要懂模式的项目经理当然愿意他的软件不是捆绑于几个程序员,而是易于维护和拓展的。

>>被代理的对象一般是不让client访问的,被装饰的对象client可以访问
代理不送赠品,装饰可能有赠品给了对象。

哈哈,freebox的比喻很形象、生动啊!

>>被代理的对象一般是不让client访问的,被装饰的对象client可以访问
代理不送赠品,装饰可能有赠品给了对象。

哈哈,freebox的比喻很形象、生动啊!

>>我们经常抱怨别人的代码很难懂,就象说各种语言的人在一起当然很难懂,如果他们都接受基础统一培训和教育,说同一种语言,那么就能够沟通了,设计模式就是程序员编代码的共同语言。

我们是否用uml来表现呢?

好像关注的人不多哦,今天再来发一个模式学习:组合模式
其实看到组合模式让人很关联到树形菜单,也许在设计树时,有些朋友会用一个类来代替treenode,因为不管是树还是树节点都是treenode组成的。这样的设计需要对treenode是不是叶子来判断,毕竟有的节点没有子节点了,我们便称其为叶子了。而组合模式让我们从另一个角度来看:设计一个Ifile接口,其有两个实现类:file和fold,在fold中内聚了Ifile,这样这个Ifile要怎么样实现就由用户自己来定义了。甚至可以再实现不一样的具体类。

记得JDON上有位牛人说过,“设计模式看到后来发现一个规律,两个字:间接”,觉得挺有道理的。