各种设计模式（个人笔记）

说明：个人笔记处于学习阶段，尚有不足之后，部分笔记属于自己理解后整理的，可能有出入。
            新人谨慎引用，高手多多指导！！！！！禁止一切商用转载，如学习转载请注明出处。

创建型模式

一、简单工厂模式

概念：属于类的创建型模式，又叫做静态工厂方法模式。通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

包含对象：

    1.工厂（Creator）角色
        简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象。

    2.抽象（Product）角色
        简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。 

    3.具体产品（Concrete Product）角色 

        简单工厂模式所创建的具体实例对象

核心：需要通过引用方给定的信息，来决定究竟创建哪个对象。

优缺点：
    优：用户在使用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。

    缺：当类增多时，工厂代码也需要做相应修改，扩展性差。

二、工厂方法模式（多态工厂模式）

    概念：定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中。核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。

包含对象：
    1.抽象工厂（Creator）角色

        工厂方法模式的核心，任何工厂类都必须实现这个接口。 

    2.具体工厂（ Concrete Creator）角色

        具体工厂类是抽象工厂的一个实现，负责实例化产品对象。 

    3.抽象（Product）角色

        工厂方法模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。 

    4.具体产品（Concrete Product）角色

        工厂方法模式所创建的具体实例对象

三、抽象工厂模式

    概念：向客户端提供一个接口，使得客户端在不必指定产品的具体类型的情况下，能够创建多个产品族的产品对象。

    包含对象：
        1.抽象工厂（Creator）角色

            抽象工厂模式的核心，包含对多个产品结构的声明，任何工厂类都必须实现这个接口。 

        2.具体工厂（ Concrete Creator）角色

            具体工厂类是抽象工厂的一个实现，负责实例化某个产品族中的产品对象。 

        3.抽象（Product）角色

            抽象模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。 

        4.具体产品（Concrete Product）角色

            抽象模式所创建的具体实例对象 

        总结：抽象工厂中方法对应产品结构，具体工厂对应产品族。

四、单例模式（类）

概念：保证该类只有一个实例存在。

存在的理由：可提高系统性能，数据一致。

实现：把构造方法私有化，提供一个静态方法（参数与构造方法参数相同），在该类中声明一个静态类对象，在return时保证返回的是同一对象。

五、原型模式

    概念：使用Prototype模式创建的实例，具有与原型一样的数据。

    实现：

    区别：

    注意：clone方式，对类中的结构性数据（如：List，Map），只会克隆地址（原有List数据修改，则都被修改）。

    浅度克隆：

    深度克隆：

六、建造者模式（针对类的属性，不同builder构造不同的属性）

    概念：简单理解，根据自己需求在给出的builder中选择一个builder，执行方法的时候将这个builder作为参数交给该类的负责人（director），最后在builder取出构造好的类。

    应用场景：类的属性有固定的值（对象）的几套模版。

七、装饰模式（包装模式）

    概念：通过一种对客户端透明的方式来扩展对象的功能，是继承关系的一个替换方案。

        （通俗理解，手抓饼（类），菜品（功能），在手抓饼中可以随心所欲的加功能，即装饰模型）

    角色和职责：
        抽象组件角色：一个抽象接口，是被装饰类和装饰类的父接口。
        具体组件角色：为抽象组件的实现类。
        抽象装饰角色：包含一个组件的引用，并定义了与抽象组件一致的接口。

        具体装饰角色：为抽象装饰角色的实现类。负责具体的装饰。

行为模式

一、策略模式

    概念：对一系列的算法加以封装，为所有算法定义一个抽象的算法接口，并通过继承该抽象算法接口对所有的算法加以封装和实现，具体的算法选择交由客户端决定（策略）。Strategy模式主要用来平滑地处理算法的切换 。

    角色和职责：
        Strategy：策略（算法）抽象。
        ConcreteStrategy：各种策略（算法）的具体实现。
        Context：策略的外部封装类，或者说策略的容器类。根据不同策略执行不同的行为。策略由外部环境决定。

    缺点：需要外部知道里面有哪些已经实现了的策略，并知道策略中的方法做的具体内容。才能加以引用。

二、观察者模式

    概念：提供给关联对象一种同步通信的手段，使某个对象与依赖它的其他对象之间保持状态同步。

    猜想实现方式：在继承的Observable类中存在一个List<Observer>用于放置观察者，当notifyObservers()方法执行时，遍历执行List所有的update方法。

    角色和职责：
        Subject（被观察者）
            被观察的对象。当需要被观察的状态发生变化时，需要通知队列中所有观察者对象。Subject需要维持（添加，删除，通知）一个观察者对象的队列列表。
       ConcreteSubject
            被观察者的具体实现。包含一些基本的属性状态及其他操作。
      Observer（观察者）
            接口或抽象类。当Subject的状态发生变化时，Observer对象将通过一个callback函数得到通知。
      ConcreteObserver

            观察者的具体实现。得到通知后将完成一些具体的业务逻辑处理。

三、解释器模式（不懂）

    概念：它建立一个解释器，对于特定的计算机程序设计语言，用来解释预先定义的文法。简单地说，Interpreter模式是一种简单的语法解释器构架。

    应用场景：

• 当有一个语言需要解释执行, 并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。而当存在以下情况时该模式效果最好：
• 该文法简单对于复杂的文法, 文法的类层次变得庞大而无法管理。此时语法分析程序生成器这样的工具是更好的选择。它们无需构建抽象语法树即可解释表达式, 这样可以节省空间而且还可能节省时间。
• 效率不是一个关键问题，最高效的解释器通常不是通过直接解释语法分析树实现的, 而是首先将它们转换成另一种形式。例如，正则表达式通常被转换成状态机。但即使在这种情况下, 转换器仍可用解释器模式实现, 该模式仍是有用的。

    角色和职责：
        Context：解释器上下文环境类。用来存储解释器的上下文环境，比如需要解释的文法等。
        AbstractExpression：解释器抽象类。

        ConcreteExpression：解释器具体实现类。

四、中介者模式

    概念：在Mediator模式中，类之间的交互行为被统一放在Mediator的对象中，对象通过Mediator对象同其他对象交互，Mediator对象起着控制器的作用。

类似房产中介的模式，中介知道（内置）多个委托人（类），委托人需要房子就只需找房产中介，由房产中介来实现方法。

    角色和职责：
        mediator 中介者类的抽象父类。
        concreteMediator 具体的中介者类。
        colleague 关联类的抽象父类。

        concreteColleague 具体的关联类。

    优点：

1. 将系统按功能分割成更小的对象，符合类的最小设计原则。
2. 对关联对象的集中控制。
3. 减小类的耦合程度，明确类之间的相互关系：当类之间的关系过于复杂时，其中任何一个类的修改都会影响到其他类，不符合类的设计的开闭原则 ，而Mediator模式将原来相互依存的多对多的类之间的关系简化为Mediator控制类与其他关联类的一对多的关系，当其中一个类修改时，可以对其他关联类不产生影响（即使有修改，也集中在Mediator控制类）。
4. 有利于提高类的重用性。

五、职责链模式

    概念：该模式构造一系列分别担当不同的职责的类的对象来共同完成一个任务，这些类的对象之间像链条一样紧密相连，所以被称作职责链模式。

    应用场景：

    基本条件：

    角色和职责：
        Handler：处理类的抽象父类。

        ConcreteHandler：具体的处理类。

    优缺点：

六、迭代模式（感觉增强for更好用）

    概念：它把对容器中包含的内部对象的访问委让给外部类，使用Iterator（遍历）按顺序进行遍历访问的设计模式。

    为什么要使用迭代模式：

    角色和职责：

    优点：

七、模版方法模式（可以结合按钮单击事件加以理解）

    概念：它把具有特定步骤算法中的某些必要的处理委让给抽象方法，通过子类继承对抽象方法的不同实现改变整个算法的行为。

    应用场景：

    角色和职责：

八、备忘录模式

    概念：它的作用是保存对象的内部状态，并在需要的时候（undo/rollback）恢复对象以前的状态。

    应用场景：

    角色和职责：

九、行为模式

    概念：State模式允许通过改变对象的内部状态而改变对象的行为，这个对象表现得就好像修改了它的类一样。

    角色和职责：

十、命令模式

    概念：Command的类封装了对目标对象的调用行为以及调用参数。

Invoker是调用者（司令员），Receiver是被调用者（士兵），MyCommand是命令，实现了Command接口，持有接收对象

    应用场景：

十一、访问者模式（被访问者固定，访问者不固定）

    概念：它分离对象的数据和行为，使用Visitor模式，可以不修改已有类的情况下，增加新的操作。

    角色和职责：

    简单理解：被访问对象固定，访问者不固定（个人感觉这个例子不错）

构造型模式

一、享元模式（对象）

    概念：通过与其他类似对象共享数据来减小内存占用。

    实现：在工厂中有一个类对象集合（一般用Map），在获取的时候需要传入键（如：传入red字符串，返回Color对象，包含rbg值）。如果未找到，则返回new一个对象返回。其后需要自己设置值（该对象里面值为空或者固定值或默认值），基础类型除外。

    区别：享元设计模式是一个类有很多对象，而单例是一个类仅一个对象；享元模式是为了节约内存空间，提升程序性能（避免大量的new操作）；而单例模式则主要是出于共享状态的目的。

二、代理模式

    概念：所谓代理，是指具有与代理元（被代理的对象）具有相同的接口的类，客户端必须通过代理与被代理的目标类交互，而代理一般在交互的过程中（交互前后），进行某些特别的处理。

    静态代理：

    动态代理：

    动态代理相对于静态代理优点：
        1、静态代理类和委托类实现了相同的接口，代理类通过委托类实现了相同的方法。这样就出现了大量的代码重复。如果接口增加一个方法，除了所有实现类需要实现这个方法外，所有代理类也需要实现此方法。增加了代码维护的复杂度。
        2、静态代理对象只服务于一种类型的对象，如果要服务多类型的对象。势必要为每一种对象都进行代理，静态代理在程序规模稍大时就无法胜任了。如上的代码是只为Subject类的访问提供了代理，但是如果还要为其他类如Subject2类提供代理的话，就需要我们再次添加代理Department的代理类。

    角色和职责：
        subject（抽象主题角色）： 真实主题与代理主题的共同接口。
        RealSubject（真实主题角色）： 定义了代理角色所代表的真实对象。
        Proxy（代理主题角色）：含有对真实主题角色的引用，代理角色通常在将客户端调用传递给真是主题对象之前或者之后执行某些操作，而不是单纯返回真实的对象。

三、适配器模式

    概念：通过Adapter模式可以改变已有类（或外部类）的接口形式。（实现功能扩展、对早期设计不足加以改进）。    1.通过继承实现    2.通过委让实现

设计模式

一、外观模式

    概念：Facade模式为一组具有类似功能的类群，比如类库，子系统等等，提供一个一致的简单的界面。这个一致的简单的界面被称作facade。（如：对外提供一个Controller，这个Controller调用多个Service层）
    优点：调用者不用关心被调用接口内部是如何实现的，这样提供了一定的安全性。

    角色和职责：
        Facade：
            为调用方定义简单的调用接口。
        Clients 调用者：
            通过Facade接口调用提供某功能的内部类群。
        Packages 功能提供者：
            指提供功能的类群（模块或子系统）。

二、组合模式

    概念：通过 递归手段来构造树形的对象结构，并可以通过一个对象来访问整个对象树。

    角色和职责：
        Component （树形结构的节点抽象）
            - 为所有的对象定义统一的接口（公共属性，行为等的定义）
            - 提供管理子节点对象的接口方法
            - [可选]提供管理父节点对象的接口方法
        Leaf （树形结构的叶节点）
            Component的实现子类
        Composite（树形结构的枝节点）

            Component的实现子类

三、桥接模式

    概念：基于类的最小设计原则，通过使用封装，聚合以及继承等行为来让不同的类承担不同的责任。它的主要特点是把抽象（abstraction）与行为实现（implementation）分离开来，从而可以保持各部分的独立性以及应对它们的功能扩展。

    角色和职责：
        Client：
             Bridge模式的使用者
        Abstraction：
             抽象类接口（接口或抽象类）
             维护对行为实现（Implementor）的引用
        Refined Abstraction：
            Abstraction子类
        Implementor：
            行为实现类接口 (Abstraction接口定义了基于Implementor接口的更高层次的操作)
        ConcreteImplementor：
            Implementor子类

    例子：jdbc连接mysql中Class.forName("com.mysql.jdbc.Driver");的作用