设计模式——命令模式

定义

命令模式:将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化,对请求排队或记录请求日志。以及支持可撤销的操作。

说白了,就是将一系列的请求命令封装起来,不直接调用真正执行者的方法,这样比较好扩展。

结构和实现

在这里插入图片描述

  • Command(抽象命令类):抽象出命令对象,可以根据不同的命令类型。写出不同的实现类

  • ConcreteCommand(具体命令类):实现了抽象命令对象的具体实现

  • Invoker(调用者/请求者):请求的发送者,它通过命令对象来执行请求。一个调用者并不需要在设计时确定其接收者,因此它只与抽象命令之间存在关联。在程序运行时,将调用命令对象的execute() ,间接调用接收者的相关操作。

  • Receiver(接收者):接收者执行与请求相关的操作,真正执行命令的对象。具体实现对请求的业务处理。未抽象前,实际执行操作内容的对象。

  • Client(客户端):在客户类中需要创建调用者对象,具体命令类对象,在创建具体命令对象时指定对应的接收者。发送者和接收者之间没有之间关系。都通过命令对象来调用。

实现

接收者

public class Receiver {
    public void action(){
        System.out.println("命令执行了.......");
    }
}

抽象命令

public interface Command {
    //调用命令
    void execute();
}

具体命令

class ConcreteCommand implements Command{
    private Receiver receiver;//持有真正执行命令对象的引用
    public ConcreteCommand(Receiver receiver) {
        super();
        this.receiver = receiver;
    }
    @Override
    public void execute() {
        //调用接收者执行命令的方法
        receiver.action();
    }
}

调用者

//请求者/调用者:发起执行命令请求的对象
public class Invoker {
    private Command command;//持有命令对象的引用
    public Invoker(Command command) {
        super();
        this.command = command;
    }
    public void call(){
        //请求者调用命令对象执行命令的那个execute方法
        command.execute();
    }
}

测试

public static void main(String[] args) {
    //通过请求者(invoker)调用命令对象(command),命令对象中调用了命令具体执行者(Receiver)
    Command command = new ConcreteCommand(new Receiver());
    Invoker invoker = new Invoker(command);
    invoker.call();
}

使用场景

甲方提出需求,需要多个部门进行协调配合,这几个部门就是真正的执行者也就是命令的接收者。但甲方不可能同时与三组交互,过于麻烦。因此需要它们找出一名代表,也就是我们的调用者。客户提出命令后,也就是让某个部门做什么,封装成一个命令后交给调用者。代表就会根据命令让对应的部门执行任务。也就是执行命令中的方法(因为命令接收者已经被嵌套在命令中了,所以直接执行命令封装好的一个执行方法即可)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
1、 FACTORY —追 MM 少不了吃饭了, 麦当劳的鸡翅和肯德基的鸡翅都是 MM 爱吃的东西, 虽然口味有所不同, 但不管你带 MM 去麦当劳或肯德基, 只管向服务员说“来四个鸡翅”就行 了。麦当劳和肯德基就是生产鸡翅的 Factory 工厂模式客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消 工厂模式 费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如 何创建及如何向客户端提供。 2、BUILDER — MM 最爱听的就是“我爱你”这句话了,见到不同地方的 MM,要能够用她们的 、 方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到 MM 我只要按对应的键, 它就能够用相应的语言说出“我爱你”这句话了, 国外的 MM 也可以轻松 搞掂,这就是我的“我爱你”builder。 (这一定比美军在 伊拉克用的翻译机好卖) 建造模式: 从而使一个建造过程生成具有不 建造模式 将产品的内部表象和产品的生成过程分割开来, 同的内部表象的产品对象。 建造模式使得产品内部表象可以独立的变化, 客户不必知道产品 内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD — MM 去麦当劳吃汉堡,不同的 MM 有不同的口味,要每个都记住 、 是一件烦人的事情,我一般采用 Factory Method 模式,带着 MM 到服务员那儿,说“要一个 汉堡”,具体要什么样的汉堡呢,让 MM 直接跟服务员说就行了。 工厂方法模式: 而是将具体创建的工作交给子类去做, 工厂方法模式 核心工厂类不再负责所有产品的创建, 成为一个抽象工厂角色, 仅负责给出具体工厂类必须实现的接口, 而不接触哪一个产品类应 当被实例化这种细节。 4、 、 PROTOTYPE —跟 MM 用 QQ 聊天, 一定要说些深情的话语了, 我搜集了好多肉麻的情话, 需要时只要 copy 出来放到 QQ 里面就行了, 这就是我的情话 prototype 了。 (100 块钱一份, 你要不要) 原始模型模式: 原始模型模式 通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原 型对象的方法创建出更多同类型的对象。 原始模型模式允许动态的增加或减少产品类, 产品 类不需要非得有任何事先确定的等级结构, 原始模型模式适用于任何的等级结构。 缺点是每 一个类都必须配备一个克隆方法。 5、 、 SINGLETON —俺有 6 个漂亮的老婆, 她们的老公都是我, 我就是我们家里的老公 Sigleton, 她们只要说道“老公”,都是指的同一个人,那就是我(刚才做了个梦啦,哪有这么好的事) 单例模式: 而且自行实例化并向整个系统提供这个实 单例模式 单例模式确保某一个类只有一个实例, 例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。 结构型模式 6、ADAPTER —在朋友聚会上碰到了一个美女 Sarah,从香港来的,可我不会说粤语,她不 、 会说普通话,只好求助于我的朋友 kent 了,他作为我和 Sarah 之间的 Adapter,让我和 Sarah 可以相互交谈了(也不知道他会不会耍我) 适配器模式: 从而使原本因接口原因不 适配器模式一个类的接口变换成客户端所期待的另一种接口, 匹配而无法一起工作的两个类能够一起工作。 适配类可以根据参数返还一个合适的实例给客 户端。 7、BRIDGE —早上碰到 MM,要说早上好,晚上碰到 MM,要说晚上好;碰到 MM 穿了件新 、 衣服, 要说你的衣服好漂亮哦, 碰到 MM 新做的发型, 要说你的头发好漂亮哦。 不要问我“早 上碰到 MM 新做了个发型怎么说”这种问题,自己用 BRIDGE 组合一下不就行了 桥梁模式:将抽象化与实现化脱耦,使得二者可以独立的变化,也就是说将他们之间的强关 桥梁模式 联变成弱关联,也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是 继承关系,从而使两者可以独立的变化。 8、COMPOSITE —Mary 今天过生日。“我过生日,你要送我一件礼物。”“嗯,好吧,去商店, 、 你自己挑。”“这件 T 恤挺漂亮,买,这条裙子好看,买,这个包也不错, 买。”“喂,买了 三件了呀,我只答应送一件礼物的哦。”“什么呀,T 恤加裙子加包包,正好配成一套呀,小 姐,麻烦你包起来。”“……”,MM 都会用 Composite 模式了,你会了没有? 合成模式:合成模式对象组织到树结构中,可以用来描述整体与部分的关系。合成模式就 合成模式一个处理对象的树结构的模式。 合成模式把部分与整体的
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

原来是肖某人

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值