抽象

李建忠提出软件开发分为两个思维方向：底层思维和抽象思维。把这两个思维方式单独分离开来，或是只注重其中一个方面，对软件开发都是有害无利的。软件设计有其本身的复杂性，各种各样的变化都对软件开发造成了不小的冲击。人们在解决问题时，不外乎分解和抽象两种方法。相应的，在解决软件开发的复杂性问题上，也是如此。面向对象设计最大的优势在于抵御变化，分解和抽象的设计方式都为简化软件开发提供的很大的便利。好的软件设计一定会有良好的复用性，这是软件设计的金科玉律。

 

在演讲中，他从各个方面阐述了如何提高软件的利用性，如何降低开发的复杂度。深入地理解面向对象开发，使用松耦合，依赖与原则的关系，等等观点都吸引了在场听众的重视。从秦国的统一标准，到毕升活字印刷的复用性，李建忠以古代历史故事为例，形象地描述了接口标准化的优势。这也是一个产业是否强盛的标志。“应对变化，提高复用”，这才是好的设计模式.

=============================================

 

今天在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
       这节课对具体的设计模式讲解的时间也不多。但是你理解了变化、稳定、复用的意义，你再看设计模式就会事半功倍。

 

       这些年的开发经验积累下来，我发现我的设计、架构很多时候都是一个四不象，或者是一个性能，可扩展性等中庸折中的取舍方案。一定要想清楚哪些是要变化的，不会变化的，不要画蛇添足的装酷。对于要变化的要做到应对变化，提高复用来抽象，高水平的技术人员，抽象出来的东西不会三天两头就变的。