Design Patterns

行为型模式 行为型模式关注于应用运行过程中算法的提供和通信关系的梳理。 相比于创建型模式和结构型模式，行为型模式包含了最多的设计模式种类，包括： 职责链模式 模板方法模式 解释器模式 命令模式 迭代器模式 中介者模式 备忘录模式 观察者模式 状态模式 策略模式 访问者模式 职责链模式 职责链模式为了避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，会将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。 GOF对外观模式的描述为： Avoid coupling the sender of a request to its receiver by giving morethan one object a chance to handle the request. Chain the receivingobjects and pass the request along the chain until an object handles it. — Design Patterns : Elements of Reusable Object-Oriented Software 在日常生活中，也会遇到类似的具有一系列“工序”的场景，比如用洗衣机洗衣服，需要经过注水、洗涤、漂洗、排水等过程，但作为使用者，我们并不需要关注这些步骤，需要做的只是把衣服放到洗衣机

什么是建造者模式 经典建造者模式的优缺点 对建造者模式的扩展 什么是建造者模式 建造者模式将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。创建者模式隐藏了复杂对象的创建过程，它把复杂对象的创建过程加以抽象，通过子类继承或者重载的方式，动态的创建具有复合属性的对象。 虽然与工厂模式、抽象工厂模式、单件模式同为创建型模式，但建造者模式与之前学习的模式相比，更为关注创建过程的细节，它一般用于创建复杂对象，从独立创建每个部分到最后的组装，它承担每个步骤的工作。由于它把创建每个部分都独立为一个单一的过程，因此不仅可以完成较为精细的创建，还可以根据创建步骤编排，生成不同的目标实例。 GOF对建造者模式的描述是： Separate the construction of a complex object from its representation so that the same construction process can create different representations.. — Design Patterns : Elements of Reusable Object-Oriented Software 创建者模式非常适用于产品局部加工过程变化较大，但组装过程相对固定的场景。 比如电脑的组装，基本的组装过程是固定的，但是具体主板、CPU

外观模式（或门面模式、包装模式）是设计模式中非常朴素地体现面向对象“封装”概念的模式，它的基本原理是将复杂的内部实现以统一接口的方式暴露出来，最大程度地减少客户程序对某些子系统内部众多对象的依赖关系。 外观模式在开发过程中运用频率非常高，比如各种第三方SDK大多会使用外观模式。通过一个外观类是的整个系统的接口只有一个统一的高层接口，这样能够降低用户的使用成本，也能够对用户屏蔽很多实现细节。 再比如经常会用到的三层结构也是外观模式的应用。 GOF对外观模式的描述为： Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. — Design Patterns : Elements of Reusable Object-Oriented Software UML类图： 通过外观模式为子系统中的一组接口提供一个高层接口，该接口使子系统更易于使用。它的主要动机是减少“子系统”内部与外部间对象通信的依赖复杂程度 再比如计算机就是一个通过提供一个高层接口以屏蔽内部复杂性的例子，计算机包括CPU、硬盘、内存等各种部件，但作为用户，不需要与这些零部件打交道

总结：相当于一个有监视器监视事件源，事件触发，之后不同的观察者去执行的逻辑 介绍 意图： 定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。 主要解决： 一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。 何时使用： 一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。 如何解决： 使用面向对象技术，可以将这种依赖关系弱化。 关键代码： 在抽象类里有一个 ArrayList 存放观察者们。 应用实例： 1、拍卖的时候，拍卖师观察最高标价，然后通知给其他竞价者竞价。 2、西游记里面悟空请求菩萨降服红孩儿，菩萨洒了一地水招来一个老乌龟，这个乌龟就是观察者，他观察菩萨洒水这个动作。 优点： 1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。 缺点： 1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。 使用场景： 图解： /designPatterns/src/com/feiyu/observer 代码结构

原型模式 原型模式的适用场景 浅拷贝 深拷贝 用Initialize方法修改初始化状态 原型模式与之前学习的各种工厂方法、单例模式、建造者模式最大、最直观的区别在于，它是从一个既有的对象“克隆”出新的对象，而不是从无到有创建一个全新的对象。与对文件的拷贝类似，原型模式是基于现有的对象拷贝新的对象。 原型模式 GOF对原型模式的描述为： Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.. — Design Patterns : Elements of Reusable Object-Oriented Software 原型模式的构造对象的的过程是，选择一个现成对象（原型对象），通过调用它的“克隆”方法来获得一个和它一样的对象。 其UML类图为： 原型模式的适用场景 原型模式适用与如下场景： Factory、Builder、Singleton返回的都是“初始状态”的对象，但有的时候需要的对象反而是处于某种状态的对象； 如果一个对象的初始化需要很多其他对象的数据准备或其他资源的繁琐计算，则可以使用原型模式直接克隆； 当需要一个对象的大量公共信息，少量字段进行个性化设置的时候

设计模式中的那些工厂 Intro 设计模式中有几个工厂模式，聊一聊这几个工厂模式的各自用法和使用示例，简单工厂（严格的来说不属于设计模式），抽象工厂，工厂方法，这几个均属于创建型模式， 所谓创建型模式，就是说这几个设计模式是用来创建对象的。 简单工厂 首先来说一说，最简单的简单工厂 简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例 严格的来说，简单工厂模式是工厂模式家族中最简单实用的模式，但不属于23种 GOF 设计模式之一。因为每次要新增类型的时候必须修改工厂内部代码，不符合开闭原则。 来看一个例子： public class OperationFactory { public static Operation CreateOperation(string operate) { Operation operation = null; switch (operate) { case "+": operation = new OperationAdd(); break; case "-": operation = new OpertaionSub(); break; case "*": operation = new OperationMul(); break; case "/": operation = new OperationDiv(); break; } return

创建型模式 简单工厂模式 工厂方法模式 IOC与工厂方法模式的结合 泛型工厂 委托工厂 创建型模式 创建型模式可以隔离客户程序对需要实例化类型的依赖关系，这类模式一般通过将实例化具体对象的职责委托给第三方对象的方式，使得客户程序或者外部系统在获得所需的具体类型实例的同时，而不必对其发生直接的引用。 创建型模式包括： 工厂方法模式 单例模式 抽象工厂模式 创建者模式 原型模式 按照大多数设计模式书籍采用的顺序，首先从工厂方法模式开始。 简单工厂模式 简单工厂模式并没有被归入23种设计模式之列，但可以作为学习工厂方法模式前的预备。简单工厂模式在管理对象创建方面，提供的是最简单的方案，它仅仅简单的对不同类对象的创建进行了一层薄薄的封装，客户程序在使用时，通过向简单工厂传递一个类型来指定要创建的对象，其UML类图如下： Client需要的是具体的产品ConcreteProductA或者ConcreteProductB，如果直接new()就会依赖对象实例，引入简单工厂后，Client变成了依赖IProduct和SampleFactory。 代码示例： //产品接口 public interface IProduct { }; //具体产品 public class ConcreteProductA : IProduct { } public class ConcreteProductB :

设计模式：学习笔记(14)——工厂方法模式 工厂方法模式 　　工厂方法模式又称为工厂模式，它属于 类创建型模式 。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是 将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。 简单工厂模式的缺点 　　在简单工厂模式中只有一个工厂类，该工厂类处于对产品类进行实例化的中心位置，它需要知道每一个产品类的实现细节，并决定何时实例化哪一个产品类。 简单工厂模式最大的缺点就是当有新产品要加入系统中时，必须修改工厂类，需要在其中加入必要的业务逻辑，这违背了开闭原则 。 　　此外，在简单工厂模式中，所有的产品都由同一个工厂创建，工厂类职责较重，业务逻辑较为复杂，具体产品与工厂类之间的耦合度高，严重影响了系统的灵活性和扩展性，而工厂方法模式则可以很好地解决这一问题。 子工厂负责创建产品 　　在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体的创建工作交给子类去做。它 仅仅负责给出具体工厂必须实现的方法，而不负责哪一个产品类被实例化这种细节 ！ 　　工厂方法的具体类图如下： 工厂方法模式，又称为工厂模式。 模式分析 模式应用 　　JDK中，也有很多使用工厂方法模式的代码，比如Collection.iterator()是生产了一个迭代器对象

组合模式 透明模式与安全模式 对组合的筛选遍历 无论是在生活中还是项目中，我们经常会遇到具有“部分-整体”概念的对象，比如员工与团队的关系，这就类似树形结构，可能具有很多的嵌套层次和分支，把这种复杂性直接暴露给调用端是不合适的。 组合模式 借助组合模式，可以将这类具有“部分-整体”的对象组合成树形的层次结构，并使得用户可以对单个对象和组合对象采用相同的使用方式。 GOF对组合模式的描述为： Compose objects into tree structures to represent part-whole hierarchies. Compositelets clients treat individual objects and compositions of objects uniformly. — Design Patterns : Elements of Reusable Object-Oriented Software UML类图： 组合模式包含三个角色： Leaf：叶子节点，代表单个个体，它没有子节点。 Composite：组合节点，既可以包含叶子节点，也可以包含其他的组合节点， Component：抽象构件，定义Leaf和Composite共有的方法和属性，可以定义一些默认的行为或属性。 透明模式与安全模式 在使用组合模式时，根据抽象构件类的定义形式

桥接模式的概念与实现 为什么叫桥接模式 桥接模式的适用场景 继承是面向对象的三大特性之一，但很多时候使用继承的结果却不尽如人意。除了人尽皆知的紧耦合问题外，有的时候还会导致子类的快速膨胀。 设想这样一个场景：最初设计的时候有一个类型Product，但后来随着新需求的出现，X原因导致了它的变化，X有两种情况，则通过继承需要创建两个新的子类ProductX1,ProductX2，但后来有出现了Y因素也会导致Product的变化，如果Y有三种情况，则会出现ProductX1Y1,ProductX1Y2,ProductX1Y3...等，一共2*3=6个类。 使用这种继承的方式，如果再出现新的变化因素，或者某个变化因素出现了新的情况，都会导致子类的快速膨胀，给维护带来很大的挑战。 造成这个问题的根本原因是类型在沿着多个维度变化。为了应对变化，一般会通过抽象的方法，找到其中比较稳定的部分，然后抽象其行为，令客户程序依赖于抽象而不是具体实现。同样的道理，当一个类型同时受到多个因素变化的影响时，也通过把每个因素抽象，让类型依赖于一系列抽象因素的办法尽量处理这个问题，这便是桥接模式解决问题的思路。 桥接模式的概念与实现 GOF对桥接模式的描述为： Decouple an abstraction from its implementationso that the two can vary