道不远人,深入.net底层技术
业精于勤荒于嬉,行成于思毁于随!

 

第一章 理解设计模式
1.1 模式的定义
什么是模式?
模式是被命名的有组织的信息,他捕获了在一定语境(场景)中包含相关作用力的问题的解决方案的本质结构和内在含义,这种解决方案被证明是成功的。
模式包括3个部分:相关的上下文与上下文相关的作用力系统解决问题的方案

*其实简单说也就是:模式的使用是在特定的环境下,处理特定问题的解决方案的通用思想。只有在环境和处理确定的情况下才可以选择正确的解决方案。

模式体现的就是平衡的思想。
模式的书写包括很多中,主要包括以下几个组成部分:
1.Name: 模式的名称反映描述的结构。但因长度有限不可能包含模式所描述的所有含义。
2.Problem:问题描述了模式的意图。(要解决的问题)
3.Context:即模式所适用的环境。
4.Forces:为了达到目标,各因素之间的相互作迎合制约,揭示了解决问题时需要考虑的各种代价。
5.Solution:解决方案给出问题的解决方法。
6.Example:实例。
7.Consenquence:在结果中需要描述应用魔术后系统的情况,其中既要描述模式的应用的效果,也要描述所付出的代价。
8.Relation Pattern:相关模式给出与这个模式相关的部分。
9.Known use:已知应用在现实中使用的实例。

 

1.2 GOF的设计模式与模式
GOF的实际模式与一般意义上的模式有很大区别。
GOF的设计模式与模式理论的区别是前者偏重于解决方案,而后者的描述更偏重于问题的描述。
在理解设计模式时,重点应该放在每个模式解决的场合和使用模式需要靠了的因素上。

 

1.3 理解模式的名称

1.4 理解模式的场景

1.5 理解模式中的作用力

1.6 理解模式的结果和代价
  1.61 对象过多
  1.62 更复杂的装配关系
  1.63 测试难度加大
  1.64 程序结构复杂

 

1.7 设计模式不能做什么
  1.71 设计模式不是法则

  模式理论的精髓之一就是模式的使用时有前提和代价的,模式是在某种前提下综合各方面因素后考虑得出的结果。
  1.72 不能提高开发速度或者形象开发速度
  在很多情况下关注的目标不是开发速度,而是程序的健壮性和可维护性。(不断的抽象、封装。对象、接口越来越多,结构越来越复杂。调试、测试越来越麻烦。当然快不了。)
  1.73 不是万能的
  设计模式的使用是自然而然的事情,很多情况下不使用模式是因为不需要,问题没有复杂到费用不可的程度。我们是为了设计而适用设计模式,而不是为了设计模式而设计。
  当你的项目发现如有下列问题之一时,就要考虑重构代码,可能会有某种模式适合。
  (1)代码无法进行单元测试。
  (2)需求的变动总是导致代码的变动。
  (3)有重复的代码存在。
  (4)继承层次过多。
  (5)隐藏的依赖过多。
  *以上的话让人深有同感。

 

1.8 设计模式的非软件示例
1.9 小结

 

=====

模式是从解决具体问题抽象出来的,这种具体问题在特定的上下文中重复出现。也就是说,每个具体形式都对一种重复的问题采用重复的解决方案。

 

 

posted on 2008-10-05 15:39  扬帆起航  阅读(218)  评论(0编辑  收藏  举报