23 个设计模式过了一遍，应该总结一下了。
比如State与Strategy，Chain of responsibility 和Decorator，Decorator 和Composite，等等在它们各自的介绍中我都提到了。这个我总结我会慢慢写。
我现在想的问题是：模式就像是建筑的技巧，（我记得有谁说模式最初是来源于建筑来着？）。可是我们的材料是如何来的呢，那一块块砖，木材，瓦片。
想当年在MCS作项目的时候，居然微软的PM（应该不是微软正式的，我不知道怎么混进去的）连什么是OO都不清楚，别说模式，我设计用了一个接口他都觉得满奇怪“你这里用个接口干什么？”我可以感觉到他面对接口这种东西时的紧张，这样得开发者，你和他说什么要面对接口编程，要依赖抽象而不是实现，恐怕是勉为其难了。而事实证明那个项目也最终是一个没有任何设计的简单的网页＋数据库的2层结构，如果你把认为类只是函数和方法集合的话，那么这个项目也可以算是面向对象。
也许有人会反驳我，很多项目就是这么简单啊，拿个锤子看见什么都是钉子，你那叫过度设计！ 呵呵，真的是这样吗？我建议现在还这样想的人去看看Robert C Martin的《敏捷软件开发》的序言：美的就是美的，丑的就是丑的，最重要的是美的东西创建起来更廉价，也更快捷。构建维护一个美的软件系统所花费的时间，金钱都要少于丑的系统。这也是我深信不疑的，丑的系统更容易创建吗？ 设计节省的时间会加快你的进度吗？也许现在国内的IT环境真的不太好，周围充斥者丑陋的系统和缺乏悟性的开发或者管理人员，让我们都无法知道什么是美的系统。
有点扯远了，好，接着瓦片。是啊，也许我们见到了一个个转头，木材是不难用点设计模式的。设计模式如果了解了内涵和我们应用一个钳子改锥工具没什么区别，关键是也许许多人连构建砖头或瓦片的意识都没有，业务逻辑层，这绝对是只出现在书本里的名词。
所以下一个目标是我会解释如何构建 业务逻辑层。这一层是即便再小的系统也不能缺的，这么绝对吗？是的，因为你是要构建美的易维护易扩展易开发的系统而不是丑的，只一层就会看见SQL语句，逻辑都犬牙交错在界面于数据访问层的系统。
明天就开始吧。
