摘要：每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心　　——Christopher Alexander　　设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。人是一个经验性的动物　　GoF 23种设计模式　　历史性著作《设计模式：可复用面向对象软件的基础》一书中描述了23种经典面向对象设计模式，创立了模式在软件设计中的地位。该书四位作者被人们并成为Gang of Four（GoF），“四人组”，该书描述的23种经典设计模式又被人们称为GoF23种设计模式。　　由于《设计 阅读全文

摘要：动机（Motivation）　　在软件构建过程中，如果某一特定领域的问题比较复杂，类似的模式不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。　　例说Interpreter应用　　假设现在要写一个程序将汉字转化为数字 　　假设我们能够把它分解为每个小部分来处理，问题就容易多了 　　上下文Context，statement是未处理的字符串，data是已经处理后的结果 　　Interpret是解释器，是Expression的核心。 　　个，十、百、千　　对于万，就比 阅读全文

摘要：耦合与变化耦合是软件不能抵御变化灾难的根本性原因。不仅实体对象与实体对象之间存在耦合关系，实体对象与行为操作之间也存在耦合关系。创建型设计模式解决的创建者和被创建对象的耦合问题；结构型设计模式解决的是实体对象和实体对象的耦合问题；行为型设计模式解决的是实体对象和行为操作之间的耦合问题。动机（Motivation）在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销/重做（undo/redo）、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二 阅读全文

摘要：直接与间接　　人们对于复杂的软件系统常常有一种处理手法，即增加一层间接层，从而对系统获得一种更为灵活、满足特定需求的解决方案。 　　假设A要访问B三次。如果A和B是分布式中的两个机器，那么A需要跨机器调用B三次就不是很好。如果在A和B之间加一个代理对象C，并且A和C处于同一个地址空间，即同一个机器。那么A和C之间通讯是非常高效的，现在A和C之间调用三次，到某个触发点的时候，和B只需要一次的通讯，这样性能就会好很多。这样做还有一个好处，即A不需要再知道分布式通讯的内容了。　　现实生活中，其实操作系统就是软件和硬件之间的代理。　　动机（Motivation）　　在面向对象系统中，有些对象由于某种 阅读全文

摘要：面向对象的代价　　面向对象很好地解决了系统抽象性的问题，同时在大多数情况下，也不会损及系统的性能。但是，在某些特殊的应用中，由于对象的数量太大，采用面向对象会给系统带来难以承受的内存开销。比如图形应用中的图元等对象、字处理应用中的字符对象等。 　　动机（Motivation）　　采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价。如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作？　　意图（Intent）　　运用共享技术有效地支持大量细粒度的对象。　　　　　　　　　　　　——《设计模式》G 阅读全文

摘要：系统的复杂度　　假设我们需要开发一个坦克模拟系统用于模拟坦克车在各种作战环境中的行为，其中坦克系统由引擎、控制器、车轮、车身等各子系统构成。 　　如何使用这样的系统 　　动机（Motivation）　　上述A方案的问题在于组件的客户（即外部接口，或客户程序）和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？　　意图（Intent）　　为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更 阅读全文

摘要：子类复子类，子类何其多　　假如我们需要为游戏中开发一种坦克，除了各种不同的型号的坦克外，我们还希望在不同场合中为其增加以下一种或多种功能：比如红外线夜视功能，比如水陆两栖功能，比如卫星定位功能等等。 　　如果再添加一种功能D，那么需要增加的T50子类的数量可想而知，而这只是T50这个类型，如果还有其他T70等类型，那么需要新添加的子类将不可计数。　　动机（Motivation）　　上述描述的问题根源在于我们“过度地使用了继承来扩展对象的功能”，由于继承为类型引入的静态特质（所谓静态特质，就是说如果想要某种功能，我们必须在编译的时候就要定义这个类，这也是强类型语言的特点。静态，就是指在编译的时候 阅读全文

摘要：对象容器的问题　　在面向对象系统中，我们常会遇到一类具有“容器”特征的对象——即它们在充当对象的同时，又是其他对象的容器。 　　如果我们要对这样的对象容器进行处理： 　　上面是客户代码，客户代码里面必须要知道对象的结构，有可能还要使用递归的方法来处理这个对象，这样写耦合性就比较高。客户代码如果能只和IBox发生依赖就很好了，但是现在它还和ContainerBox和SingleBox发生了依赖，这样内部实现的细节就暴露给了外界，并且和外界产生了依赖关系。　　动机（Motivation）　　上述描述的问题根源在于：客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器内部实现结构（而非抽象接 阅读全文

摘要：抽象与实现　　抽象不应该依赖于实现细节，实现细节应该依赖于抽象。 　　问题在于如果抽象B由于固有的原因，本身并不稳定，也有可能变化，怎么办？　　举例来说　　假如我们需要开发一个同时支持PC和手机的坦克游戏，游戏在PC和手机上功能都一样，都有同样的类型，面临同样的功能需求变化，比如坦克可能有很多种不同的型号：T50，T75，T90……对于其中的坦克设计，我们可能很容易设计出来一个Tank的抽象基类，然后各种不同型号的Tank继承自该类; 　　另外的变化原因　　但是PC和手机上的图形绘制、声效、操作等实现完全不同……因此对于各种型号的坦克，都要提供各种不同平台上的坦克实现： 　　这样的设计会带来 阅读全文

摘要：从耦合关系谈起 　　耦合关系直接决定着软件面对变化时的行为　　-模块与模块之间的紧耦合使得软件面对变化时，相关模块都要随之更改 　　-模块与模块之间的松耦合使得软件面对变化时，一些模块更容易被替换或者更改，但其他模块保持不变 　　抽象部分变化慢，细节（具体）部分变化快；高层部分变化慢，底层部分变化快。　　当我们对于系统的认识无法梳理出上面的图时，最好不要一开始就用设计模式，设计模式其实是一个演绎的... 阅读全文

摘要：依赖关系的倒置 　　抽象不应该依赖于实现细节，实现细节应该依赖于抽象。-抽象A直接依赖于实现细节b（软件易脆，很容易需要重新编译） 　　-抽象A依赖于抽象B，实现细节b依赖于抽象B 　　动机（Motivation）　　在软件系统中，经常面临着“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。如何应对这种变化？如... 阅读全文

摘要：适配（转换）的概念无处不在 　　适配，即在不改变原有实现的基础上，将原先不兼容的接口转换为兼容的接口。 　　动机（Motivation）　　在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境... 阅读全文