【转载】"变化"、"复用"、"抽象"、"稳定" 影响着软件设计模式，架构，开发方法...

【本文转载自CSDN论坛：http://topic.csdn.net/u/20081209/10/39b3b38a-0376-45e5-b878-b0305a573712.html】

      今天在SD2大会上，听了李建忠老师讲的《.NET框架中的几个典型设计模式》课程收益非浅，李建忠老师的课总能给人醍醐灌顶的感觉，去年的《WPF内核机制》让我们可以从根本上理解WPF的革命。今年的设计模式，也是从根本上理解设计模式产生的原因，适用的场景。 
      下面是我对课程整理的一些笔记和心得，跟大家分享： 
      软件的需求一直在变化。很变态，但是很多人都碰到过的情况：一直到代码编写完毕前，需求都可能在变化，需求的冻结要到编码完毕时才完成。
      为此，软件的开发方法从最初的瀑布开发， 到迭代开发再到敏捷开发。他们都是适应软件的需求、设计迟迟不能冻结定稿的产物。上面提到的开发方法，一个比一个需求、设计定稿的时间要晚。
      当然，变化不能一直不稳定，那么我们软件就永远不能发布了。 
      软件的架构也受到这些影响：
      我们预计到会变的因素我们会写在配置文件ini或者XML配置文件中。
      甚至我们预计要变得东西单单配置文件都不可以搞定了，我们要把这些预计要变的东西写成解析执行的脚本语言。今天早上蔡学镛讲的《Scriptable Software与DSL的设计》，下午周爱民讲的《JavaScript + Delphi + ErLang = ？》从这里提到的变化角度来说，都是为了适应这种变化对架构的影响采用的方法。
      [魔兽世界]编写插件用的LUA语言，[文明4]用的Python语言...都是这方面的典范。 
      对于设计模式，也同样的是受变化影响的。
      我们预计到一个地方是稳定的，就一个选择，我们如果还用设计模式，就是愚蠢的性能低下的做法。设计模式应该用到我们预计到这里会发生变化，为了保证复用性，我们对变化进行抽象，抽象出一个稳定的抽象。抽象出来的这个类，如果时不时都会变化一下，那简直要疯了，这个抽象的类一定要保证稳定性。这才是OO思想,设计模式的思想.
      应对变化，提高复用，这是OO设计的基本原则,也是设计模式的基本原则。
      晚绑定机制就是对这些变化的支持。.NET的晚绑定有四种方法：虚函数，委托（函数指针），反射，范型。对应的23种设计模式都是用这些来实现的。 
      MSDN的WebCast中，李建忠老师对C#设计模式有25节课的讲座，详细介绍了23种设计模式。在下面地址可以看到，下载：http://www.microsoft.com/china/msdn/events/webcasts/shared/webcast/consyscourse/CsharpOOD.aspx 
      这节课对具体的设计模式讲解的时间也不多。但是你理解了变化、稳定、复用的意义，你再看设计模式就会事半功倍。 
      这些年的开发经验积累下来，我发现我的设计、架构很多时候都是一个四不象，或者是一个性能，可扩展性等中庸折中的取舍方案。一定要想清楚哪些是要变化的，不会变化的，不要画蛇添足的装酷。对于要变化的要做到应对变化，提高复用来抽象，高水平的技术人员，抽象出来的东西不会三天两头就变的。

转载于:https://www.cnblogs.com/daxnet/archive/2009/07/03/1686974.html