• 设计模式学习笔记


    参考博客:

    博客1

    博客2

     

    简单工厂模式

    一、什么是简单工厂模式

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

    二、模式中包含的角色及其职责

    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)角色
    抽象模式所创建的具体实例对象
    
    总结:抽象工厂中方法对应产品结构,具体工厂对应产品族。

     

    单例模式

    一、什么是单例模式

       单例模式是一种对象创建型模式,使用单例模式,
    可以保证为一个类只生成唯一的实例对象。也就是说,
    在整个程序空间中,该类只存在一个实例对象。
        其实,GoF对单例模式的定义是:保证一个类、
    只有一个实例存在,同时提供能对该实例加以访
    问的全局访问方法。 

    二、为什么要使用单例模式呢?

    在应用系统开发中,我们常常有以下需求:
    - 在多个线程之间,比如servlet环境,共享同一个资源或者操作同一个对象
    - 在整个程序空间使用全局变量,共享资源
    - 大规模系统中,为了性能的考虑,需要节省对象的创建时间等等。
    
    因为Singleton模式可以保证为一个类只生成唯一的实例
    对象,所以这些情况,Singleton模式就派上用场了。

    三、单例模式实现

    1.饿汉式。
    2.懒汉式。
    3.双重检查。

    原型模式

    一、什么是原型模式

        Prototype模式是一种对象创建型模式,它采
    取复制原型对象的方法来创建对象的实例。使用
    Prototype模式创建的实例,具有与原型一样的
    数据。

    二、原型模式的特点

    1. 由原型对象自身创建目标对象。也就是说,对
    象创建这一动作发自原型对象本身。
    2.目标对象是原型对象的一个克隆。也就是说,
    通过Prototype模式创建的对象,不仅仅与原型
    对象具有相同的结构,还与原型对象具有相同的
    值。
    3.根据对象克隆深度层次的不同,有浅度克隆与
    深度克隆。

    三、原型模式应用场景

    - 在创建对象的时候,我们不只是希望被创建的对象继承
    其基类的基本结构,还希望继承原型对象的数据。
    
    - 希望对目标对象的修改不影响既有的原型对象(深度克
    隆的时候可以完全互不影响)。
    
    - 隐藏克隆操作的细节。很多时候,对对象本身的克隆需
    要涉及到类本身的数据细节。 

    建造者模式

    一、什么是建造者模式

       Builder模式也叫建造者模式或者生成器模式,
    是由GoF提出的23种设计模式中的一种。Builder模式是一种对象创建型模式之一,用来
    隐藏复合对象的创建过程,它把复合对象的创建
    过程加以抽象,通过子类继承和重载的方式,动
    态地创建具有复合属性的对象。

    二、建造者模式的结构

    三、建造者模式应用场景 

    - 对象的创建:Builder模式是为对象的创建而设计的模式
    - 创建的是一个复合对象:被创建的对象为一个具有复合属性的复合对象
    - 关注对象创建的各部分的创建过程:不同的工厂(这里指builder生成器)对产品属性有不同的创建方法

    装饰模式

    一、什么是装饰模式

       装饰( Decorator )模式又叫做包装模式。通
    过一种对客户端透明的方式来扩展对象的功能,
    是继承关系的一个替换方案。

    二、装饰模式的结构

    三、装饰模式的角色和职责

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

    策略模式

    一、什么是策略模式

       Strategy模式也叫策略模式是行为模式之一,
    它对一系列的算法加以封装,为所有算法定义一
    个抽象的算法接口,并通过继承该抽象算法接口
    对所有的算法加以封装和实现,具体的算法选择
    交由客户端决定(策略)。Strategy模式主要用
    来平滑地处理算法的切换 。

    二、策略模式的结构

    三、策略模式的角色和职责 

    Strategy:
           策略(算法)抽象。
    
    ConcreteStrategy
        各种策略(算法)的具体实现。
    
    Context
        策略的外部封装类,或者说策略的容器类。根据不同策略执行不同的行为。策略由外部环境决定。 

     四、策略模式的优点

    它的优点有:
    1. 策略模式提供了管理相关的算法族的办法。策略类的等级结构定
    义了一个算法或行为族。恰当使用继承可以把公共的代码移到父类
    里面,从而避免重复的代码。
    2. 策略模式提供了可以替换继承关系的办法。继承可以处理多种算
    法或行为。如果不是用策略模式,那么使用算法或行为的环境类就
    可能会有一些子类,每一个子类提供一个不同的算法或行为。但
    是,这样一来算法或行为的使用者就和算法或行为本身混在一起。
    决定使用哪一种算法或采取哪一种行为的逻辑就和算法或行为的逻
    辑混合在一起,从而不可能再独立演化。继承使得动态改变算法或
    行为变得不可能。
    3. 使用策略模式可以避免使用多重条件转移语句。多重转移语句不
    易维护,它把采取哪一种算法或采取哪一种行为的逻辑与算法或行
    为的逻辑混合在一起,统统列在一个多重转移语句里面,比使用继承的办
    法还要原始和落后。
    策略模式的缺点有:
    1. 客户端必须知道所有的策略类,并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别,以便适时选择恰当的算法类。换言之,策略模式只适用于客户端知道所有的算法或行为的情况。
    
    2. 策略模式造成很多的策略类。有时候可以通过把依赖于环境的状态保存到客户端里面,而将策略类设计成可共享的,这样策略类实例可以被不同客户端使用。换言之,可以使用享元模式来减少对象的数量。

    观察者模式

    一、什么是观察者模式

    Observer模式是行为模式之一,它的作用是当
    一个对象的状态发生变化时,能够自动通知其他
    关联对象,自动刷新对象状态。
    
    Observer模式提供给关联对象一种同步通信的
    手段,使某个对象与依赖它的其他对象之间保持
    状态同步。

    二、观察者模式的结构

    三、观察者模式的角色和职责

    Subject(被观察者)
        被观察的对象。当需要被观察的状态发生变化时,需要通知队列中所有观察者对象。Subject需要维持(添加,删除,通知)一个观察者对象的队列列表。
    
    ConcreteSubject
        被观察者的具体实现。包含一些基本的属性状态及其他操作。
    
    Observer(观察者)
        接口或抽象类。当Subject的状态发生变化时,Observer对象将通过一个callback函数得到通知。
    
    ConcreteObserver
        观察者的具体实现。得到通知后将完成一些具体的业务逻辑处理。

     四、观察者模式的典型应用 

    Observer模式的典型应用
    - 侦听事件驱动程序设计中的外部事件
    - 侦听/监视某个对象的状态变化
    - 发布者/订阅者(publisher/subscriber)模型中,当一个外部事件(新的产品,消息的出现等等)被触发时,通知邮件列表中的订阅者

    享元模式

    一、什么是享元模式

       Flyweight模式也叫享元模式,是构造型模式之
    一,它通过与其他类似对象共享数据来减小内存
    占用。

    二、享元模式的结构

    三、享元模式的角色和职责

    抽象享元角色:
          所有具体享元类的父类,规定一些需要实现的公共接口。
    
    具体享元角色:
        抽象享元角色的具体实现类,并实现了抽象享元角色规定的方法。
    
    享元工厂角色:
        负责创建和管理享元角色。

    代理模式

    一、什么是代理模式

       Proxy模式又叫做代理模式,是构造型的设计
    模式之一,它可以为其他对象提供一种代理(Proxy)以
    控制对这个对象的访问。
    
        所谓代理,是指具有与代理元(被代理的对象)具有
    相同的接口的类,客户端必须通过代理与被代理的目标
    类交互,而代理一般在交互的过程中(交互前后),进
    行某些特别的处理。

    二、代理模式的结构

    三、代理模式的角色和职责

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

    四、动态代理

    1. InvocationHandler 接口
    2. invoke方法
    3. Proxy.newProxyInstance();

    外观模式

    一、什么是外观模式

       Facade模式也叫外观模式,是由GoF提出的
    23种设计模式中的一种。Facade模式为一组具
    有类似功能的类群,比如类库,子系统等等,提
    供一个一致的简单的界面。这个一致的简单的界
    面被称作facade。

    二、外观模式的结构

    三、外观模式的角色和职责

    Facade
        为调用方定义简单的调用接口。
    
    Clients
        调用者。通过Facade接口调用提供某功能的内部类群。
    
    Packages
        功能提供者。指提供功能的类群(模块或子系统)。

    组合模式

    一、什么是组合模式

        Composite模式也叫组合模式,是构造型的设
    计模式之一。通过递归手段来构造树形的对象结
    构,并可以通过一个对象来访问整个对象树。

    二、组合模式的结构

    三、组合模式的角色和职责

    Component (树形结构的节点抽象)
    - 为所有的对象定义统一的接口(公共属性,行为等的定义)
    - 提供管理子节点对象的接口方法
    - [可选]提供管理父节点对象的接口方法
    
    Leaf (树形结构的叶节点)
    Component的实现子类
    
    Composite(树形结构的枝节点)
    Component的实现子类 

    桥接模式

    一、什么是桥接模式

         Bridge 模式又叫做桥接模式,是构造型的设
    计模式之一。Bridge模式基于类的最小设计原则,通过
    使用封装,聚合以及继承等行为来让不同的类承担不同
    的责任。它的主要特点是把抽象(abstraction)与行为
    实现(implementation)分离开来,从而可以保持各部
    分的独立性以及应对它们的功能扩展。

    二、桥接模式的结构

    三、桥接模式的角色和职责

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

    适配器模式

    一、什么是适配器模式

         Adapter模式也叫适配器模式,是构造型模式之一
    ,通过Adapter模式可以改变已有类(或外部类)的接
    口形式。

    二、适配器模式应用场景

       在大规模的系统开发过程中,我们常常碰到诸如以下这些情况:
    我们需要实现某些功能,这些功能已有还不太成熟的一个或多个外
    部组件,如果我们自己重新开发这些功能会花费大量时间;所以很
    多情况下会选择先暂时使用外部组件,以后再考虑随时替换。但这
    样一来,会带来一个问题,随着对外部组件库的替换,可能需要对
    引用该外部组件的源代码进行大面积的修改,因此也极可能引入新
    的问题等等。如何最大限度的降低修改面呢?
    Adapter模式就是针对这种类似需求而提出来的。
    Adapter模式通过定义一个新的接口(对要实现的功能加以抽象),
    和一个实现该接口的Adapter(适配器)类来透明地调用外部组件。
    这样替换外部组件时,最多只要修改几个Adapter类就可以了,其他
    源代码都不会受到影响。

    三、适配器模式的结构

    1.通过继承实现Adapter

    2.通过委让实现Adapter 

      

    解释器模式

    一、什么是解释器模式

       Interpreter模式也叫解释器模式,是行为模式之一,它
    是一种特殊的设计模式,它建立一个解释器,对于特定
    的计算机程序设计语言,用来解释预先定义的文法。简
    单地说,Interpreter模式是一种简单的语法解释器构架。

    二、解释器模式应用场景

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

    三、解释器模式的结构

    三、解释器模式的角色和职责

    Context
        解释器上下文环境类。用来存储解释器的上下文环境,比如需要解释的文法等。
    
    AbstractExpression
        解释器抽象类。
    
    ConcreteExpression
        解释器具体实现类。  

    中介者模式

    一、什么是中介者模式

       Mediator模式也叫中介者模式,是由GoF提出的23种
    软件设计模式的一种。Mediator模式是行为模式之一,
    在Mediator模式中,类之间的交互行为被统一放在
    Mediator的对象中,对象通过Mediator对象同其他对象
    交互,Mediator对象起着控制器的作用。

    二、中介者模式的结构

    三、中介者模式的角色和职责

    mediator
        中介者类的抽象父类。
    concreteMediator
        具体的中介者类。
    colleague
     关联类的抽象父类。
    concreteColleague
        具体的关联类。

    四、中介者模式的优点

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

    职责链模式

    一、什么是职责链模式

       Chain of Responsibility(CoR)模式也叫职
    责链模式或者职责连锁模式,是行为模式之一,
    该模式构造一系列分别担当不同的职责的类的对
    象来共同完成一个任务,这些类的对象之间像链
    条一样紧密相连,所以被称作职责链模式。

    二、职责链模式的应用场景

         例1:比如客户Client要完成一个任务,这个任务包括a,b,c,d四个部分。
    首先客户Client把任务交给A,A完成a部分之后,把任务交给B,B完成b部分,...,直到D完成d部分。
    例2:比如政府部分的某项工作,县政府先完成自己能处理的部分,不能处理的部分交给省政府,省政府再完成自己职责范围内的部分,不能处理的部分交给中央政府,中央政府最后完成该项工作。
    例3:软件窗口的消息传播。
    例4:SERVLET容器的过滤器(Filter)框架实现。 

    三、职责链模式的基本条件

       要实现Chain of Responsibility模式,需要满足该模式
    的基本条件:
    1,对象链的组织。需要将某任务的所有职责执行对象以链的形式加以组织。
    2,消息或请求的传递。将消息或请求沿着对象链传递,以让处于对象链中的对象得到处理机会。
    3,处于对象链中的对象的职责分配。不同的对象完成不同的职责。
    4,任务的完成。处于对象链的末尾的对象结束任务并停止消息或请求的继续传递。  

    四、职责链模式的结构

    五、职责链模式的角色和职责

    Handler 
        处理类的抽象父类。
    concreteHandler 
        具体的处理类。

     六、职责链模式的优缺点

    优点:
    1。责任的分担。每个类只需要处理自己该处理的工作(不该处理的传递给下一个对象完成),明确各类的责任范围,符合类的最小封装原则。
    2。可以根据需要自由组合工作流程。如工作流程发生变化,可以通过重新分配对象链便可适应新的工作流程。
    3。类与类之间可以以松耦合的形式加以组织。
    缺点:
    因为处理时以链的形式在对象间传递消息,根据实现方式不同,有可能会影响处理的速度。 

    迭代模式

    一、什么是迭代模式

       Iterator模式也叫迭代模式,是行为模式之
    一,它把对容器中包含的内部对象的访问委让给
    外部类,使用Iterator(遍历)按顺序进行遍历
    访问的设计模式。

    二、不使用迭代模式的应用

    在应用Iterator模式之前,首先应该明白Iterator
    模式用来解决什么问题。或者说,如果不使用
    Iterator模式,会存在什么问题。
    1.由容器自己实现顺序遍历。直接在容器类里直接添加顺序遍历方法 
    2.让调用者自己实现遍历。直接暴露数据细节给外部。

    三、不使用迭代模式的缺点

    以上方法1与方法2都可以实现对遍历,这样有问、
    题呢?
    1,容器类承担了太多功能:一方面需要提供添加删除等本身应有的功能;一方面还需要提供遍历访问功能。
    2,往往容器在实现遍历的过程中,需要保存遍历状态,当跟元素的添加删除等功能夹杂在一起,很容易引起混乱和程序运行错误等。

    四、使用迭代模式的应用

       Iterator模式就是为了有效地处理按顺序进行遍历访问
    的一种设计模式,简单地说,Iterator模式提供一种有效
    的方法,可以屏蔽聚集对象集合的容器类的实现细节,
    而能对容器内包含的对象元素按顺序进行有效的遍历访
    问。
    
    所以,Iterator模式的应用场景可以归纳为满足以下几个
    条件:
    - 访问容器中包含的内部对象
    - 按顺序访问

    五、迭代模式的结构

    五、迭代模式的角色和职责 

    Iterator(迭代器接口):
    该接口必须定义实现迭代功能的最小定义方法集
    比如提供hasNext()和next()方法。
    
    ConcreteIterator(迭代器实现类):
    迭代器接口Iterator的实现类。可以根据具体情况加以实现。
    
    Aggregate(容器接口):
    定义基本功能以及提供类似Iterator iterator()的方法。
    
    concreteAggregate(容器实现类):
    容器接口的实现类。必须实现Iterator iterator()方法。 

    六、迭代模式的优点

    1,实现功能分离,简化容器接口。让容器只实现本身的基本功能,把迭代功能委让给外部类实现,符合类的设计原则。
    2,隐藏容器的实现细节。
    3,为容器或其子容器提供了一个统一接口,一方面方便调用;另一方面使得调用者不必关注迭代器的实现细节。
    4,可以为容器或其子容器实现不同的迭代方法或多个迭代方法。 

    模板方法模式

    一、什么是模板方法模式

       Template Method模式也叫模板方法模式,是
    行为模式之一,它把具有特定步骤算法中的某些
    必要的处理委让给抽象方法,通过子类继承对抽
    象方法的不同实现改变整个算法的行为。

    二、模板方法模式的应用场景

    Template Method模式一般应用在具有以下条件
    的应用中:
    - 具有统一的操作步骤或操作过程
    - 具有不同的操作细节
    - 存在多个具有同样操作步骤的应用场景,但某些具体的操作细节却各不相同

    二、模板方法模式的结构

    三、模板方法模式的角色和职责 

    AbstractClass:
    抽象类的父类
    ConcreteClass:
    具体的实现子类
    templateMethod():
    模板方法
    method1()与method2():
    具体步骤方法  

    备忘录模式

    一、什么是备忘录模式

       Memento模式也叫备忘录模式,是行为模式之
    一,它的作用是保存对象的内部状态,并在需要
    的时候(undo/rollback)恢复对象以前的状态。

    二、备忘录模式的应用场景

       如果一个对象需要保存状态并可通过undo或rollback等
    操作恢复到以前的状态时,可以使用Memento模式。
    1)一个类需要保存它的对象的状态(相当于Originator角色)
    2)设计一个类,该类只是用来保存上述对象的状态(相当于Memento角色)
    3)需要的时候,Caretaker角色要求Originator返回一个Memento并加以保存
    4)undo或rollback操作时,通过Caretaker保存的Memento恢复Originator对象的状态

    三、备忘录模式的结构

    四、备忘录模式的角色和职责

    Originator(原生者)
        需要被保存状态以便恢复的那个对象。
    Memento(备忘录)
        该对象由Originator创建,主要用来保存Originator的内部状态。
    Caretaker(管理者)
        负责在适当的时间保存/恢复Originator对象的状态。

    状态模式

    一、什么是状态模式

       State模式也叫状态模式,是行为设计模式的
    一种。State模式允许通过改变对象的内部状态
    而改变对象的行为,这个对象表现得就好像修改
    了它的类一样。 

    二、状态模式的应用场景

      状态模式主要解决的是当控制一个对象状态转
    换的条件表达式过于复杂时的情况。把状态的判
    断逻辑转译到表现不同状态的一系列类当中,可
    以把复杂的判断逻辑简化。

    三、状态模式的结构

    四、状态模式的角色和职责

    Context:用户对象
    拥有一个State类型的成员,以标识对象的当前
    状态; 
    State:接口或基类
    封装与Context的特定状态相关的行为; 
    ConcreteState:接口实现类或子类
    实现了一个与Context某个状态相关的行为。 

    命令模式

    一、什么是命令模式

       Command模式也叫命令模式 ,是行为设计模
    式的一种。Command模式通过被称为
    Command的类封装了对目标对象的调用行为以
    及调用参数。

    二、命令模式的应用场景

      在面向对象的程序设计中,一个对象调用另一个对象,
    一般情况下的调用过程是:创建目标对象实例;设置调
    用参数;调用目标对象的方法。
    但在有些情况下有必要使用一个专门的类对这种调用
    过程加以封装,我们把这种专门的类称作command类。
    - 整个调用过程比较繁杂,或者存在多处这种调用。
    这时,使用Command类对该调用加以封装,便于功能的
    再利用。
    - 调用前后需要对调用参数进行某些处理。
    - 调用前后需要进行某些额外处理,比如日志,缓存,记录历史操作等。 

    三、命令模式的结构

    四、命令模式的角色和职责

    Command
        Command抽象类。
    
    ConcreteCommand
        Command的具体实现类。
    
    Receiver
        需要被调用的目标对象。
    
    Invorker
        通过Invorker执行Command对象。

    访问者模式

    一、什么是访问者模式

       Visitor模式也叫访问者模式,是行为模式之一
    ,它分离对象的数据和行为,使用Visitor模式,
    可以不修改已有类的情况下,增加新的操作。

    二、访问者模式的应用示例

        比如有一个公园,有一到多个不同的组成部分;该公
    园存在多个访问者:清洁工A负责打扫公园的A部分,清
    洁工B负责打扫公园的B部分,公园的管理者负责检点各
    项事务是否完成,上级领导可以视察公园等等。也就是
    说,对于同一个公园,不同的访问者有不同的行为操
    作,而且访问者的种类也可能需要根据时间的推移而变
    化(行为的扩展性)。
    根据软件设计的开闭原则(对修改关闭,对扩展开
    放),我们怎么样实现这种需求呢?

    三、访问者模式的结构

    四、访问者模式的角色和职责

    1) 访问者角色(Visitor):
         为该对象结构中具体元素角色声明一个访问操作接口。该操作接
    口的名字和参数标识了发送访问请求给具体访问者的具体元素角色。
    这样访问者就可以通过该元素角色的特定接口直接访问它。 
    2) 具体访问者角色(Concrete Visitor):
         实现每个由访问者角色(Visitor)声明的操作。 
    3) 元素角色(Element):
          定义一个Accept操作,它以一个访问者为参数。 
    4) 具体元素角色(Concrete Element):
         实现由元素角色提供的Accept操作。 
    5) 对象结构角色(Object Structure):
          这是使用访问者模式必备的角色。它要具备以下特征:能枚举
    它的元素;可以提供一个高层的接口以允许该访问者访问它的元
    素;可以是一个复合(组合模式)或是一个集合,如一个列表或一个无序
    集合。 

    开放封闭原则

    一、什么是开放封闭原则

       开放封闭原则(Open-Closed Principle):一个软件实体
    应当对扩展开放,则修改关闭。
       在设计一个模块时,应当使得这个模块可以在不被修
    改的前提下被扩展。也就是说,应当可以在不必修改源
    代码的情况下修改这个模块的行为。
       设计的目的便在于面对需求的改变而保持系统的相对
    稳定,从而使得系统可以很容易的从一个版本升级到另
    一个版本。

    二、怎样做到开放封闭原则

         实际上,绝对封闭的系统是不存在的。无论模块是怎
    么封闭,到最后,总还是有一些无法封闭的变化。而我
    们的思路就是:既然不能做到完全封闭,那我们就应该
    对那些变化封闭,那些变化隔离做出选择。我们做出选
    择,然后将那些无法封闭的变化抽象出来,进行隔离,
    允许扩展,尽可能的减少系统的开发。当系统变化来临
    时,我们要及时的做出反应。
          我们并不害怕改变的到来。当变化到来时,我们首
    先需要做的不是修改代码,而是尽可能的将变化抽象出
    来进行隔离,然后进行扩展。面对需求的变化,对程序
    的修改应该是尽可能通过添加代码来实现,而不是通过
    修改代码来实现。

    三、繁忙的银行业务员

    四、轻松的银行业务员

    三、开放封闭原则的优越性

       1.通过扩展已有的软件系统,可以提供新的行
    为,以满足对软件的新需求,是变化中的软件有
    一定的适应性和灵活性。
       2.已有的软件模块,特别是最重要的抽象模
    块不能再修改,这就使变化中的软件系统有一定
    的稳定性和延续性。 

    单一职责原则

    一、什么是单一职责原则

    单一职责原则(Single Responsibility Principle ):
           就一个类而言,应该仅有一个引起它变化的
    原因。

    二、多功能的山寨手机

    山寨手机的功能:
           拍照、摄像、手机游戏、网络摄像头、GPS、炒股
    等等。
    
    功能多、但是每一个功能都不强。
    拍摄功能 ------专业摄像机或照相机
    手机游戏 ------PSP
    网络摄像头----专业摄像头
    GPS功能------专业GPS导航系统

    三、烦人的山寨手机

        每一个职责都是一个变化的轴线,当需求变化
    时会反映为类的职责的变化。如果一个类承担的
    职责多于一个,那么引起它变化的原因就有多个。
    一个职责的变化甚至可能会削弱或者抑制类完成
    其他职责的能力,从而导致脆弱的设计。

    四、单一职责原则示例

    接受客户端输入并提交到数据库。
    原有设计:
        一个类负责接受客户端输入,对客户端输入进
    行校验,连接数据库,并提交数据到数据库。
    
    现有设计:
        一个功能也就是一个职责由一个类来负责。

    三里氏代换原则

    一、什么是里氏代换原则

    里氏代换原则(Liskov Substitution Principle):
        一个软件实体如果使用的是一个父类的话,那
    么一定适用于其子类,而且它察觉不出父类和子
    类对象的区别。也就是说,在软件里面,把父类
    替换成它的子类,程序的行为没有变化。

    二、反过来的代换不成立

    里氏代换原则(Liskov Substitution Principle):
        一个软件实体如果使用的是一个子类的话,那
    么它不能适用于其父类。

    三、企鹅是鸟类吗??

    四、正方形是一种长方形吗??

     五、好骗的Java编译器

     

    六、原来还有一个四边形的概念?

     

    依赖倒转原则

    一、什么是倒转?

    二、什么是依赖倒转原则

    依赖倒转(Dependence Inversion Principle ):
        1.抽象不应该依赖于细节,细节应该依赖于抽
    象。
        2.高层模块不依赖底层模块,两者都依赖抽象。

    三、组装电脑

    四、怎样做到依赖倒转

    1.工厂方法模式
    2.模板方法模式
    3.迭代子模式 

    迪米特法则

    一、什么是迪米特法则

       迪米特法则(Law of Demeter )又叫做最少知识
    原则,也就是说,一个对象应当对其他对象尽可
    能少的了解。
        迪米特法则最初是用来作为面向对象的系统设
    计风格的一种法则,于1987年秋天由lan holland
    在美国东北大学为一个叫做迪米特的项目设计提
    出的。

    二、狭义的迪米特法则

       如果两个类不必彼此直接通信,那么这两个类
    就不应当发生直接的相互作用。如果其中一个类
    需要调用另一类的某一个方法的话,可以通过第
    三者转发这个调用。

    三、和陌生人说话

    四、不要和陌生人说话 

     

    五、与依赖倒转原则结合

     

    六、走后门看病

     

    七、办理手续住院

  • 相关阅读:
    BZOJ2199[Usaco2011 Jan]奶牛议会——2-SAT+tarjan缩点
    BZOJ3862Little Devil I——树链剖分+线段树
    BZOJ2325[ZJOI2011]道馆之战——树链剖分+线段树
    BZOJ1018[SHOI2008]堵塞的交通——线段树
    BZOJ2733[HNOI2012]永无乡——线段树合并+并查集+启发式合并
    BZOJ4127Abs——树链剖分+线段树
    bzoj 4753 最佳团体
    bzoj 4472 salesman
    bzoj 5369 最大前缀和
    bzoj 1226 学校食堂Dining
  • 原文地址:https://www.cnblogs.com/biaogejiushibiao/p/10358471.html
Copyright © 2020-2023  润新知