摘要：
定义 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。 UML 优点 缺点 应用场景 示例 通过访问者来访问不同对象并打印对应访问者刚兴趣的数据出来。 Java 1 import java.util.ArrayList; 2 import ja 阅读全文
随笔档案-2016年10月
行为类模式（十）：模板方法（Template Method）
2016-10-27 15:12 by 阿诚de窝, 282 阅读, 收藏, 编辑
摘要：
定义 定义一个操作中的算法的骨架，而将步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义算法的某些特定步骤。 UML 优点 缺点 应用场景 示例 使用模板方法来读取XML和数据库中的数据。 Java 1 import java.util.HashMap; 2 import java 阅读全文
行为类模式（九）：策略（Strategy）
2016-10-27 15:09 by 阿诚de窝, 403 阅读, 收藏, 编辑
摘要：
定义 针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。 UML 优点 缺点 应用场景 示例 考虑一个销售的场景，针对不同的客户销售的产品有不同的优惠。 Java 1 public class Main 2 { 阅读全文
行为类模式（八）：状态（State）
2016-10-27 15:06 by 阿诚de窝, 342 阅读, 收藏, 编辑
摘要：
定义 当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。 状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。 UML 优点 缺点 应用场景 示例 实现一个电梯运行的程序，电梯的几个状态之 阅读全文
行为类模式（七）：观察者（Observer）
2016-10-27 14:59 by 阿诚de窝, 339 阅读, 收藏, 编辑
摘要：
定义 定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。 UML 优点 缺点 应用场景 示例 实现一个简单的观察者和被观察者的示例。 Java 1 import java.util.ArrayList; 2 import java.util.Lis 阅读全文
行为类模式（六）：备忘录（Memento）
2016-10-27 14:57 by 阿诚de窝, 261 阅读, 收藏, 编辑
摘要：
定义 在不破坏封闭的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。 UML 优点 缺点 应用场景 示例 使用备忘录模式备份和还原一个状态。 Java 1 public class Main 2 { 3 public static void ma 阅读全文
行为类模式（五）：中介者（Mediator）
2016-10-27 14:53 by 阿诚de窝, 473 阅读, 收藏, 编辑
摘要：
定义 定义一个中介对象来封装系列对象之间的交互。中介者使各个对象不需要显示地相互引用，从而使其耦合性松散，而且可以独立地改变他们之间的交互。 试想一下，如果多个类之间相互都有引用，那么当其中一个类修改时，势必导致所有相关联的类都需要修改，如果引入一个中介类来管理所有类的交互，即所有类都通过中介类和其 阅读全文
行为类模式（四）：迭代器（Iterator）
2016-10-27 14:51 by 阿诚de窝, 246 阅读, 收藏, 编辑
摘要：
定义 提供一种方法访问一个容器（container）对象中的各个元素，而又不暴露该对象的内部细节。 UML 优点 缺点 应用场景 示例 考虑这样一个需求，一家大公司合并了一家小公司，而两家公司的工资系统不一样，大公司使用List记录员工工资，小公司使用数组记录员工工资，而这两个不一样的工资系统需要合 阅读全文
行为类模式（三）：解释器（Interpreter）
2016-10-27 14:48 by 阿诚de窝, 302 阅读, 收藏, 编辑
摘要：
定义 给定一个语言, 定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。 UML 优点 缺点 应用场景 示例 使用解释器模式完成一个两则运算器，要求输入表达式和每个符号的值得到表达式的最终结果。 Java 1 import java.io.BufferedReader; 阅读全文
行为类模式（二）：命令（Command）
2016-10-27 14:42 by 阿诚de窝, 276 阅读, 收藏, 编辑
摘要：
定义 将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。 UML 优点 缺点 应用场景 示例 用命令模式模拟主机按下开机按钮后主机内部的开机流程。 Java 1 public class Main 2 { 3 public st 阅读全文
行为类模式（一）：职责链（Chain Of Responsibility）
2016-10-27 14:39 by 阿诚de窝, 327 阅读, 收藏, 编辑
摘要：
定义 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。 将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。 UML 优点 缺点 应用场景 示例 我们来实现一个场景，请求聚餐费用时，一般是把请求提交到项目经理处，项目经理可以处理500元以下的费用，如果费用 阅读全文
结构类模式（七）：代理（Proxy）
2016-10-27 14:35 by 阿诚de窝, 388 阅读, 收藏, 编辑
摘要：
定义 为其他对象提供一种代理以控制对这个对象的访问。 代理模式也叫做委托模式，它是一项基本设计技巧。许多其他的模式，如状态模式、策略模式、访问者模式本质上是在更特殊的场合采用了委托模式，而且在日常的应用中，代理模式可以提供非常好的访问控制。 代理类负责对真实角色的应用，把所有抽象主题类定义的方法限制 阅读全文
结构类模式（六）：享元（Flyweight）
2016-10-27 14:20 by 阿诚de窝, 227 阅读, 收藏, 编辑
摘要：
定义 运用共享技术有效的支持大量细粒度的对象。 两个状态 和对象池的区别 UML 优点 缺点 应用场景 示例 我们考虑一个场景，当我们需要自己实现绘制艺术字时，每一个字符都会有下面的几个状态：1.字体轮廓（这部分就是最耗内存的部分，每个字体都会有大量的数据来记录该字体的样式）；2.字体字符（标志该字 阅读全文
结构类模式（五）：外观（Facade）
2016-10-27 14:17 by 阿诚de窝, 372 阅读, 收藏, 编辑
摘要：
定义 为子系统中的一组接口提供一个一致的界面，定义一个高层接口，这个接口使得这一子系统更加容易使用。 UML 优点 缺点 应用场景 示例 假设我们的项目中有一个代码生成工具，用来生成供前后端使用的代码，客户端在调用时需要先加载配置文件，然后再依次生成前后端的代码文件，这个顺序不能乱掉。我们如果直接提 阅读全文
结构类模式（四）：装饰（Decorator）
2016-10-27 14:13 by 阿诚de窝, 310 阅读, 收藏, 编辑
摘要：
定义 动态地将责任附加到对象上.若要扩展功能,装饰者提供了比继承更有弹性的替代方案。 它是通过创建一个包装对象，也就是装饰来包裹真实的对象。 特点 UML 优点 缺点 应用场景 示例 实现一个奖金计算的程序，奖金的计算是比较复杂的，普通员工有每月的业绩奖金和累计奖金，如果是经理每月还有团队奖金，而公 阅读全文
结构类模式（三）：组合（Composite）
2016-10-27 14:00 by 阿诚de窝, 348 阅读, 收藏, 编辑
摘要：
定义 将对象组合成树形结构以表示“部分整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。 有时候又叫做部分-整体模式，它使我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。 比较常见的有 阅读全文
结构类模式（二）：桥接（Bridge）
2016-10-27 13:54 by 阿诚de窝, 294 阅读, 收藏, 编辑
摘要：
定义 将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化。 在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度 阅读全文
结构类模式（一）：适配器（Adapter）
2016-10-27 13:51 by 阿诚de窝, 334 阅读, 收藏, 编辑
摘要：
定义 适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。 类适配器模式 使用继承的方式实现没有提供的接口从而达到适配到新系统的需求。 对象适配器模式 使用聚合的方式提供新系统需要的所有接口。 UML 优点 缺点 应用场景 经典例子 阅读全文
创建类模式（五）：单例（Singleton）
2016-10-27 13:47 by 阿诚de窝, 358 阅读, 收藏, 编辑
摘要：
定义 确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。 单例模式一般情况下通过使用private的构造函数确保了在一个应用中只产生一个实例，并且是自行实例化。 和静态变量的区别 虽然都是在任意地方可以访问到，但是静态变量或全局变量不能限制一个应用中只存在指定类的一个实例，而单例可以 阅读全文
创建类模式（四）：原型（Prototype）
2016-10-27 13:43 by 阿诚de窝, 359 阅读, 收藏, 编辑
摘要：
定义 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 原型模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节,工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。 UML 优点 缺点 应用场景 阅读全文
创建类模式（三）：创建者（Builder）
2016-10-27 13:39 by 阿诚de窝, 328 阅读, 收藏, 编辑
摘要：
定义 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。这使得构件算法和组装方式可以独立应对变化；复用同样的构建算法可以创建不同的表示，不同的构建过程可以复用相同的部件组装方式。 和工厂模式的区别 UML 优点 在创建者模式中，客户端不再负责对象的创建与组装，而是把这个对象创 阅读全文
创建类模式（二）：抽象工厂（Abstract Factory）
2016-10-27 13:36 by 阿诚de窝, 337 阅读, 收藏, 编辑
摘要：
定义 为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类。 抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。抽象工厂模式是指当有多个抽象角色时，使用的一种工厂模式。抽象工厂模式可以向客户端提供一个接口，使客户端在不必指定产品的具体的情况下，创建多个产品族中的产品对 阅读全文
创建类模式（一）：工厂方法（Factory Method）
2016-10-27 13:34 by 阿诚de窝, 764 阅读, 收藏, 编辑
摘要：
定义 此模式的核心精神是封装类中不变的部分，提取其中个性化善变的部分为独立类，通过依赖注入以达到解耦、复用和方便后期维护拓展的目的。 定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中。核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一 阅读全文
创建类模式（零）：简单/静态工厂（Static Factory）
2016-10-27 13:32 by 阿诚de窝, 462 阅读, 收藏, 编辑
摘要：
定义 简单工厂模式属于创建型模式，但不属于23种GOF设计模式之一，这也是为什么该模式标记为零的原因。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。 UML 优点 工厂类是整个模式的关键.包含了必要的逻 阅读全文
设计原则（六）：开闭原则
2016-10-27 13:29 by 阿诚de窝, 371 阅读, 收藏, 编辑
摘要：
定义 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。 开闭原则算是前5中原则的一个抽象总结，前五种是开闭原则的一些具体实现，所以如果使用开闭原则，其实有点虚，因为它没有一个固定的模式，但是最终保证的是提高程序的复用性、可维护性等要求。 阅读全文
设计原则（五）：迪米特法则
2016-10-27 13:27 by 阿诚de窝, 220 阅读, 收藏, 编辑
摘要：
定义 一个对象应该对其他对象保持最少的了解。 类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。 软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。 问题 老师类的上课点名方法里依赖学生类，学 阅读全文
设计原则（四）：接口隔离原则
2016-10-27 13:24 by 阿诚de窝, 244 阅读, 收藏, 编辑
摘要：
定义 客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。 问题 如图： 类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体 阅读全文
设计原则（三）：依赖倒置原则
2016-10-27 13:22 by 阿诚de窝, 249 阅读, 收藏, 编辑
摘要：
定义 高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 问题 高层模块A如果依赖底层模块B，由于底层模块会经常变动，所以每当B出现修改时会牵动到高层的模块A，而作为高层的模块必然又会导致所有依赖A的模块的变动。 解决 模块A不应该依赖模块B。 阅读全文
设计原则（二）：里氏替换原则
2016-10-27 13:19 by 阿诚de窝, 258 阅读, 收藏, 编辑
摘要：
定义 继承必须确保超类所拥有的性质在子类中仍然成立。任何基类可以出现的地方，子类一定可以出现。 也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系。 父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵 阅读全文
设计原则（一）：单一职责原则
2016-10-27 13:17 by 阿诚de窝, 296 阅读, 收藏, 编辑
摘要：
定义 一个类应该只有一个发生变化的原因。 所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。 果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职 阅读全文
