概述 在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。那么如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？这就是本文要说的Adapter 模式。 意图 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作

概述 在 软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧 烈的变化，但是将它们组合在一起的算法确相对稳定。如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的 “稳定构建算法”不随着需求改变而改变？这就是要说的建造者模式。 本文通过现实生活中的买KFC的例子

（1）意图 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 （2）适用性 1. 当创建复杂对象的算法应该独立于该对象的组成部分以及他们的装配方式；2. 当构造过程必须允许构造的对象有不同的表示； （3）结构 （4）参与者 　　　　Builder：为创建一个Product对象的各个部件指定抽象接口 　　　　ConcreteBuilder：1. 实现Builder的

近来发现很多ASP.NET MVC的例子中都使用了Repository模式，比如Oxite，ScottGu最近发布的免费的ASP.NET MVC教程都使用了该模式。就简单看了下。在《企业架构模式》中，译者将Repository翻译为资源库。给出如下说明：通过用来访问领域对象的一个类似集合的接口，在领域与数据映射层之间进行协调。在《领域驱动设计：软件核心复杂性应对之道》中，译者将Repository

概述 Singleton模 式要求一个类有且仅有一个实例，并且提供了一个全局的访问点。这就提出了一个问题：如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？客户程 序在调用某一个类时，它是不会考虑这个类是否只能有一个实例等问题的，所以，这应该是类设计者的责任，而不是类使用者的责任。 从另一个角度来说，Singleton模式其实也是一种职责型模式。因为我们创建了一个对象，这个对象扮演了

概述 在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？这就是我们要说的抽象工厂模式。 意图 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 模型图 逻辑模型： 物理模型： 生