距上次在博客园发帖子已有一段时间了，总是太懒的写，尽管一直想写。这些日子又重玩本科时期玩的热火朝天的游戏，玩游戏的感觉和以前并无二异，只是我不再年轻而已。年轻真好，年轻的女孩子即使再惨淡也让人喜欢，只是我年轻的时候没有意识到或者意识到也没有重视，只是平淡的面对别人的称羡。日子已是一天天过去，年华渐渐老去，只是这些年，仍是寂寞的，我曾以为可以感动别人，最后发现，我所能感动的只是我自己而已。

如果想通过我的文字有什么收获的话，可能要让您失望了。写技术文章不是我的优势，因为我的理解也不深入。我只是想在这里讲一个故事，一个不算成功的故事。看过博客园上评论比较多的文章，大部分都不是讲什么技术，或者技术含量不高。人总是喜欢看到别人比自己弱的，我也是这样。总喜欢把自己和别人比，欣喜着自己对别人的优越，同时别人也同样的欣赏着我的失败，而我也非常喜欢向别人讲述自己的失败。

一件东西是否优越，不在于它有多先进，而在于有多少人用它，人总是喜欢墨守成规的，不愿意轻易改变。人是万物的精灵。这篇文章就是从人的角度，至少是从我的角度，而不是从技术的角度来描述我的认识，关于框架和模式，当然少不了我的感慨。感慨只是蹉跎了生命，并没有带来任何实质性的改变，我仍然是不良于行的浑浑噩噩者。总在该努力的时候放纵自己，总在机会面前畏缩不前。就这样子，过了十年，过了我生命中最好的年华，永远不会再有了。

我文字中闲扯的本领，并不能改变我生活中的沉默寡言。回到正题，说说框架。人总是希望自己少做一点而别人多做一点，同样程序也是这样。所以软件代替了硬件的工作，批处理文件代替了打卡机，COM+升级到.net。即使发展到今天，我们还是要作大量的冗余工作的，于是框架出现了，把大部分我们不喜欢的做的重复性东西交给框架去处理。框架就象山上修的道路，也许没有框架，我们会更自由，但过度的自由可能导致迷失方向。前Windows时代也许最出名的框架就是MFC，齐名的还有OWL，如果这仅是由一个人设计，那可以说那人是天才。当我们看的时候都会被迷宫一般的代码扰乱，设计它的人只能说是心中大有丘壑。天才和常人不一样的地方就是凭一己之力改变历史。当年，评价C#和Dephi的始创者就是一句话，“他简直是神”，天才已经超越了他的时代所能想到的范围，比如高斯，去测量田地都能发现测地线。天才夺天地之造化，所以大都早死。如黎曼，不满五十岁，穷困而死，阿贝尔，不满30，穷困而死，拉马努金没有受过高等教育，凭自己的自学重造数学四百年历史，也是早死。我能用自己的思维诠释程序100来年的历史（从Ada起），就已心满意足。天才的命运除个别意外，大抵如此。所以我并不想成为什么天才，我只想健健康康活着，能有一个女人不离不弃，再有两个孩子。就心满意足了。使用MFC还是要了解一些内幕的，不然就会对编译中出现的错误莫名其妙。MFC只算是win32s上薄薄的一层，Win Forms的封装更进了一步，也就更简单。毕竟new一个Form比CreateWindowsEx简单明了，方便记忆。但我们的Form仍然对应有Native Window，所以Win32s还是适用的。

以前初学Windows编程的时候，还不知道什么是面向对象。每次编译的时候都提心吊胆的等待错误出现。面向过程结构化设计中，函数是构造的最小单位。我记得最深的就是这么一个意思，如果函数的名称不能用一个动词来描述所有功能的话，就要将它拆成几个函数。以后慢慢了解了什么是OOP，然而思维总是很难转变。不知道现在的C++.net是否还是一趟编译。

框架的出现极大的解放了程序员。他给我们一种选择，可以让我们只需要关心该关心的东西。“程序员是软件IC工厂的男工女工”，这句话是候捷，也就是候俊杰说的。当你一旦依赖于框架时，那你就不得不去学习。所以我们不得不从ISAPI学到asp，再到ASP.net 1.1,2.0,3.5.微软的一举一动就会让我们学习半天，时刻不停的追随它的脚步。有时候并不是我们愿意学，而是公司要求不得不学。君不见各种招聘信息上都要求全才，数据库要精通SQL Server,Oracle,DB2,Information,服务器要通晓Apache，Jboss，Tomcat,Web Logic,WebSphere,常用的框架要掌握Stuts,Spring,WebWork等，当然还少不了.net下的这些框架，我不了解，不敢献丑。

如果不考虑以后的维护和修改，我们不用框架和模式的效率会更高。但框架的设计目的是通用，所以应用模式就自然的要用到。模式通常应用引入多余的类来达到底耦合的目的。比如工厂模式要多一个工厂类。现在流行的是反射工厂和依赖注入模式，以前的抽象工厂渐渐被取代。这主要是由于高级语言对反射的支持，MFC对反射的实现是为每种类引入静态Cruntimeclass，.net的实现是在PE文件头中对其有描述，这在COM时代就有类似的做法了，不过那时是放在一个单独的文件中，对于Java反射机制的实现现在还不清楚，望诸君明以教我。或许这些细节的东西没有什么用处，我也曾见过不理解什么是继承，分不清行缓冲和全缓冲的老程序员，但那我又能做什么呢，细节的东西永远学不完，就象流行的技术永远学不完一样，我们永远不知道明年流行什么。

这些日子又看了看设计模式，我只是笼统的描述一下我的认识，水平有限，错误请指出。

一般来说，面向接口编程是不变的准则，不暴露细节是我们追求的目标。将可能变化的部分分离开来是设计模式的主要方法。当变化的对象功能相近，方法相同时可以考虑工厂模式，比如DataBase Connection，使用工厂模式可以让我们不必在乎是SQLConnection还是OracleConnection。若对象相差太远，但方法相同时，我们可以构造同一个接口，使用生成器模式，当对象功能相近，但方法不同时，可以考虑访问者模式或中介者模式等；我们要把一些接口不同的改成相同，可以考虑适配器或外观模式，若对原有的接口上增加功能可以采用装饰器模式，不增加原来的接口，但要增强控制等目的的时候可以考虑代理模式，比如根据测试和正式应用而有所选择的时候。当然也不绝对，这时我们用工厂模式同样可以达到目的。模式的巧妙是存乎一心的东西，就象断卦一样，每个人对卦象都有自己的看法。

写的太混乱，看着也费劲，胡言乱语半天，我都不知道说的什么东西，先这样罢。