摘要： 9月，我换了一家公司。办公室是大间，都是隔断的，相互间看不见。 但相邻格子间打电话却是听得一清二楚。 我左边的同事，似乎是个很黏老婆的男人。 “老婆，今天晚上我想吃红烧肉哦。” “老婆，那件灰格子的衬衣熨了没有？明天我要穿的哦。” “老婆，我又馋你的葱油饼了。” 刻意压低的声音竟然糯糯软软的。我在心里暗笑，这男人是在向他老婆撒... 阅读全文

摘要： 引言不知道来到这里的朋友，有多少知道今何在的《悟空传》，又或者有人还记得自己看《悟空传》时的情景的。还记得的朋友不妨留个言，我们做个小小的统计。那震撼人心的誓言，不是一个平庸的人可以杜撰出来的：我要这天，再遮不住我眼，我要这地，再埋不了我心，要这众生，都明白我意，要那诸佛，都烟消云散！取经的四个人代表了这世上四类拼搏着的四类人：唐僧（金蝉子）看破了世事沉浮，看穿了佛意真伪，为了真义敢于用千年的修行... 阅读全文

摘要： 动机：　　在软件构建过程中，如果某一特定领域的问题比较复杂，类似的模式不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。　　在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。意图：　　给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。　　出自：《设计模式》GoFInter... 阅读全文

摘要： 动机：　　在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合－－比如需要对行为进行“记录、撤销/重做（Undo/Redo）、事务”等处理，这种无法抵御变化的紧耦合是不合适的。　　在这种情况下，如何将“行为请求者”与“行为实现解耦？将一... 阅读全文

摘要： 动机：　　在软件构建的过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现。　　如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？意图：　　定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义... 阅读全文

摘要： 动机：　　在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。　　如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。意图：　　为其他对象提供一种代理以控制对这个对象的访问。　　出自：《设计模式》GoFProxy模式的几个要点：　　１、... 阅读全文

摘要： 动机：　　采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价－－主要指内存需求方面的代价。　　如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作？　　意图：　　运用共享技术有效地支持大量细粒度的对象。　　出自：《设计模式》GoFFlyweight模式的几个要点：　　１、面向对象很好地解决了抽象性的问题，但是作为一个运行在... 阅读全文

摘要： 动机：　　如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化的内部子系统的变化之间的依赖相互解耦？意图：　　为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。　　出自：《设计模式》GoFFacade模式的几个要点：　　１、从客户程序的角度来看，Facade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说... 阅读全文

摘要： 动机：　　如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀的问题？从而使得任何“功能扩展变化”所导致的影响降为最低？意图：　　动态地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类更为灵活。　　出自：《设计模式》GoFDecorator模式的几个要点：　　... 阅读全文

摘要： 动机：　　客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器内部实现结构（而非抽象接口）的变化将客户代码的频繁变化，带来了代码的维护性差、扩展性差等弊端。　　如何将“客户代码与复杂的对象容器结构”解耦？让对象容器自己来实现自身的复杂结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器？意图：　　将对象组合成结构以表示“部分－整体”的层... 阅读全文