.NET设计模式(1):开篇

.NET设计模式开篇

——.NET设计模式系列之一

Terrylee20051206

前言

加入Design & Pattern团队有几个月的时间了,惭愧的是从没有写过关于设计模式的随笔,得到wayfarer的同意,把企业库系列的随笔放在了团队的首页上。不是不想去写这样的随笔,也不是没有时间,自己初学设计模式,去写设计模式的文章,有点班门弄斧的味道。园子里吕震宇老师的《设计模式系列》和wayfarer的《设计之道》堪称设计模式里的经典之作。可是正如wafarer所说的那样,受到发表欲的蛊惑,本着交流就是进步的想法,思考再三,还是决定写这样的随笔,来对设计模式做一些探索和总结,起名曰“探索设计模式”,有些言过其实,就当是记录自己学习设计模式的历程吧,不过还是希望能得到各位前辈的指点!

设计模式

设计模式是规则吗?

地上本没有路,走得人多了也就成了路。设计模式如同此理,它是经验的传承,并非体系;是被前人发现,经过总结形成了一套某一类问题的一般性解决方案,而不是被设计出来的定性规则;它不像算法那样可以照搬照用。

设计模式是架构吗?

架构和模式应该是一个属于相互涵盖的过程,但是总体来说架构更加关注的是所谓的High-Level Design,而模式关注的重点在于通过经验提取的准则或指导方案在设计中的应用,因此在不同层面考虑问题的时候就形成了不同问题域上的模式。模式的目标是,把共通问题中的不变部分和变化部分分离出来。不变的部分,就构成了模式,因此,模式是一个经验提取的准则,并且在一次一次的实践中得到验证,在不同的层次有不同的模式,小到语言实现,大到架构。在不同的层面上,模式提供不同层面的指导。

设计模式,软件的永恒之道?

这个问题没有答案,有的只是讨论,看一下一位前辈结合建筑学得出的几点心得吧:

和建筑结构一样,软件中亦有诸多的内力。和建筑设计一样,软件设计也应该努力疏解系统中的内力,使系统趋于稳定、有生气。一切的软件设计都应该由此出发。

任何系统都需要有变化,任何系统都会走向死亡。作为设计者,应该拥抱变化、利用变化,而不是逃避变化。

好的软件只能产生而不能创造,我们所能做的只是用一个相对好的过程,尽量使软件朝向好的方向发展。

需要设计模式吗?

答案是肯定的,但你需要确定的是模式的应用是否过度?我得承认,世界上有很多天才的程序员,他可以在一段代码中包含6 种设计模式,也可以不用模式而把设计做得很好。但我们的目标是追求有效的设计,而设计模式可以为这个目标提供某种参考模型、设计方法。

我们不需要奉GOF的设计模式为圭臬,但合理的运用设计模式,才是正确的抉择。很多人看过GOF的《Design Patterns》,对这23 种模式也背得滚瓜烂熟。但重要的不是你熟记了多少个模式的名称,关键还在于付诸实践的运用。为了有效地设计,而去熟悉某种模式所花费的代价是值得的,因为很快你会在设计中发现这种模式真的很好,很多时候它令得你的设计更加简单了。

其实在软件设计人员中,唾弃设计模式的可能很少,盲目夸大设计模式功用的反而更多。言必谈“模式”,并不能使你成为优秀的架构师。真正出色的设计师,懂得判断运用模式的时机。还有一个问题是,很多才踏入软件设计领域的人员,往往对设计模式很困惑。对于他们来说,由于没有项目的实际经验,OO 的思想也还未曾建立,设计模式未免过于高深了。其实,即使是非常有经验的程序员,也不敢夸口对各种模式都能合理应用。[--摘自wayfare的设计之道]

后记

关于设计模式的理论性的文章,已经写了很多了,我不想再继续重复抄写下去,仅记录下上面几段话,用它来作探索设计模式系列的一个开篇吧。[现已更名为.NET设计模式]

posted @ 2005-12-09 08:59  TerryLee  阅读(70599)  评论(45编辑  收藏  举报