ColorPicTips on Getting StartedColorPic

随笔 - 4  文章 - 7  trackbacks - 0
<2008年8月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456

After you've installed the ColorPic you might be wondering how to get started picking colors. Use the tips below to get started selecting colors and use a few advanced features that you might not have know about too.

常用链接

留言簿(1)

随笔档案

文章分类

文章档案

相册

http://cwj-0122.cnblogs.com/

搜索

  •  

最新评论

阅读排行榜

评论排行榜

这次这个主题还是关于设计模式的,在早期的一篇已经写了,一直到现在还没继续完成他。而为什么又写这主题呢?因为,这跟前面的主题确有不同之处,这回主要阐述了设计模式的进化问题。
到了今天,终于有点时间完成这主题了...
目录结构:
1.基本概念
2.基础结构
3.基于基础结构的模式演化过程
其实这样的层次是很简单了,在基础结构诞生之后,基于委托的模式已经算是很明了的了。然后,大概介绍几个基于委托的模式的演化过程
1.基本概念
这里列出了几个相关概念。
委托
临时委托
DIP原则
客户
中介者(我叫它为管理器和调度器,当然,在不同模式中,取名有所差别)
目标对象
2.基本结构
编程中,当你需要某种服务,你当然会去调用具有该服务的目标对象(有可能是更高层次的组件),很显然,结果,就是这样一个的结构。client调用ClassA来实现某种服务。

比如,为了处理字符串,你会new String,然后进行一些处理。甚至,你的代码里到处都充砌着String的足迹,这样确实能很好的解决问题。这样的结构背后的理由呢?首先,我想说的是,这样的结构违反了DIP原则,细节应该依赖于抽象,而不是依赖于另一个细节。这样的依赖关系会使代码缺乏弹性,很难复用,迁一发动全身。应该改进的是,把ClassA的抽象提取出来,然后让client去依赖于IClassA,变成如下图: 
 

但是,事实上,我们没有这么做。这是因为String这样的类实例具有很强的稳定性,这样的稳定性保证了它不会经常变化,这就是行为的稳定性因素。这样具有强稳定性的类没必要复杂化。所以,我们让接受了client依赖于细节的结果。这样的细节是单一的。
然而,需求是变化的,解决方案是不稳定的,在我们的项目中,会有大量不具稳定性的因素存在。在项目中,你会发现存在着多个同性质而实现细节有异的行为类存在。
比如存在着这样的三个类ClassA,ClassB, ClassC,
client在不同地方调用它。结构图如下: 
 

我假设client是个main函数,OK,调用的代码应该是这样,
void main(){
        ...
       ClassA a = new ClassA();

(1)    a.MethodOne();
(2)    for(int i=0;i<3;i++){
(3)       a.MethodTwo();
(4)    }
       .....

       ClassB b = new ClassB();
(5)    b.MethodOne();
(6)    for(int i=0;i<3;i++){
(7)       b.MethodTwo();
(8)    }

}
这样的代码,给你的感觉怎么样,也许还蛮过得去,他确实是跑得起来。但这样的代码存在潜在的危险性。应该被归入糟糕设计的范畴里。首先,客户面对不具稳定性的因素,根据DIP原则,它没有提取抽象,违反了DIP原则。其次,client(main)必须负责策略的组织(我把类似(1)(2)(3)(4)的目标对象的这样一组调用过程称为策略组织),也就是说,client面对的不是一个完全的黑盒子,他面对的是一些半黑的盒子,同时,他必须知道怎么把这些半黑的盒子组装起来。例如(5)(6)(7)(8)这些对客户来说,是一组半黑的盒子。客户本身的任务太重了,同时,这样的任务弥漫在客户的头和脚之间,及其零乱。很快,又有类似的另一种不具稳定性的因素参与这样的弥漫活动,最终的客户将被淹没在不稳定性因素组成的大海里。如果,刚好是你在负责这样的客户编码,我,很同情你。重构吧,老兄。
不满意,好,我们做第一次修改,根据DIP原则,我们提取这三个类的抽象。比如IClass, 然后,大家都实现他。然后,把ClassA a = new ClassA(); 改为IClass a = new ClassA();OK,很好的遵循了DIP原则。然后,我们需要有一个参与者,我称该类为Context或(Manager,mediator),它的职责很简单,仅仅负责半黑盒子的组装。我们没有给予他过多的职责。SRP的违反同样让人觉得可怕。并把IClass作为一个委托对象属性传递给它。结构图如下: 
 

这样,客户很轻松的从半黑盒子的策略组织中脱离出来,它只管在Context与这三个类之间进行装配,而装配的方式,你可以自由选择任何一种注入方式。例如:
你给Context装配一个ClassB。
Context context = new Context(new ClassB());
OK,针对于不稳定性因素的解决方案的基础结构出来了。这也是基于委托的设计模式的基础。这样的模型具有潜在的进化与退化问题。
1.Context是个具体类,具有不稳定性,有着往抽象方向的进化。
2.A线上是个委托属性。有着往临时委托方向的退化。
3.B线上create过程有从客户向Context转移的变化性。
4.Context的组织权有着向IClass转移的可能性。
在下面的继续中,我们会从基本型中根据这四个进化与退化以及委托的意义,演变出不同的模式。 同时,我会把各个模式自身的进化与退化做个简介(自身的演化可能演变成别的模式)
等待继续.....
posted on 2008-08-14 12:54 zhqh 阅读(1386) 评论(5)  编辑  收藏

FeedBack:
# re: 设计模式之进化论(1) 2008-08-14 16:15 zhuxing
继续  回复  更多评论
  
# re: 设计模式之进化论(1)[未登录] 2008-08-14 22:29 aaa
狗屁不通! 抄书!  回复  更多评论
  
# re: 设计模式之进化论(1) 2008-08-15 12:24 zhuxing
@aaa
不能这么说。
楼主写的可能过于抽象  回复  更多评论
  
# re: 设计模式之进化论(1) 2008-08-15 16:01 ccc
继续  回复  更多评论
  
# re: 设计模式之进化论(1) 2008-08-17 18:11 dell电脑
给收藏起来了,以后要是能变成一本电子书就好了。  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航:
博客园   IT新闻   Chat2DB   C++博客   博问  
 

aaaaaaaaaaaaaaaaaaaaaa