design-patterns - 命令模式不仅仅是适配器吗？

Question

根据 GoF 命令模式 UML，在我看来，ConcreteCommand只是使Reciever适应通用命令（可能是）接口。我可能被金锤击中了，所以请解释一下区别在哪里或者我做错了什么。

Answer 1

许多这些模式看起来非常相似，并且意图确实有助于理解模式定义。这是我对这些模式的（可能不完整）知识：

命令模式将调用者与操作分开。

一个命令可能有一个独立于特定请求、接收者或调用者的生命周期——它是一个单独的第一类实体。它允许在不同时间排队和执行命令，并允许记录/记住命令执行，可能用于日志记录。

它可用于组织 UI 命令实现、撤消或重做功能或事务管理作为示例。

适配器模式用于使一个对象适应另一个对象的使用。

我不会混淆对另一个对象进行操作的对象（ConcreteCommand 对 Receiver 执行某些操作）与“适配器”模式的实现相混淆，其中适配器的行为几乎就像一个代理，以允许 Adaptee 与其他协作者一起工作。

Answer 2

两者本质上是不同的。让我解释一下原因：

如果不使用命令模式，您将无法乘飞机从一个地方旅行到另一个地方！

如果您经常旅行，作为客户，您所关心的只是从您所在的地方旅行到另一个地方。您不关心飞行员将如何驾驶飞机或哪家航空公司可用..您无法真正预测到这一点。你想要的只是去机场并告诉他们带你去你的目的地。但如果你这样做，你对机场当局的指挥会被嘲笑！他们需要你提供一个命令对象，这是你的票。尽管您不关心哪家航空公司或哪种飞机类型，但当您准备好飞行时，您需要提供票务命令对象。调用者，即机场官员需要检查您的命令（机票），以便他们可以验证它，如果它是假的则撤消它，如果他们犯了错误则重做它（您不必重新完成预订过程） . 简而言之 ，他们希望在决定是否调用或执行您的命令之前完全控制您的命令（票证），这让航空公司（接收者）执行（让您登上飞机并带您前往目的地）。请注意，您的命令（您的机票）已经拥有接收者（航空公司）的信息，没有这些信息，机场官员甚至不会首先开始处理您的机票。

机场当局甚至可能有一堆他们正在处理的机票。他们可能会选择延迟我的票并让在我之后的人通过（在我之前调用另一个人的票）

如果不使用适配器模式，您将无法像往常一样进行交易！

过去一段时间，主要的交易方式是通过面糊：如果你想要我的笔记本电脑，把你的台式机和电视给我。问题是你可能没有我想要的，所以我们不能交易。解决方案是适配器模式。我们无法交易，因为我们有不兼容的接口（想要）。所以发明了钱。因此，现在如果您想要我的笔记本电脑，请通过适配器，典当它并获得一些钱。是的！我肯定想要一些钱。几乎每个人都实现了称为 Money 的抽象类（或以 Dollars 为实例的 IMoney）。你？现在与命令模式相反，money 上没有关于接收者的信息。我希望金钱是我作为接收者的命令对象。那会很酷。但不是！虽然可以调用、撤消或重做票证等，但始终接受金钱。如果你给我一些，我会做一件事：接受它。

Answer 3

在命令模式中，命令对象知道能够完成给定请求的人。或者它也可能知道完成请求所需的所有人员。（例如：如果请求是“洗衣服”，Command对象得到衣服，找到洗衣机，放入洗涤剂，旋转机器并完成该过程。对于这些动作，它可以调用其他人（对象）。

在适配器模式中，适配器不认识能够完成工作的人。它也对请求或如何完成工作一无所知。它所做的只是调用另一个实现了不兼容接口的人。

Answer 4

适配器是-a 或具有-a 适配器。具体的命令有一个接收器。所以箭头朝另一个方向移动。