命令模式比适配器更多吗？

Question

根据GoF Command Pattern UML，我觉得 ConcreteCommand 只是将 Reciever 改编为常见的 Command （可能是）接口。我可能会遇到golden hammer，所以请解释一下差异在哪里或我出错了什么。

Answer 1

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

命令模式将调用者从操作中分离出来。

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

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

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

我不会将操作在另一个对象上的对象（ConcreteCommand对Receiver执行某些操作）与“Adapter”模式的实现混淆，其中Adapter几乎像代理一样，允许Adaptee与其他协作者一起工作。 / p>

Answer 2

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

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

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

机场当局甚至可能会收到一堆他们正在处理的门票。他们可能会选择延迟我的机票，让跟在我后面的人通过（在我之前调用另一张人的票）

如果不使用适配器模式，您无法照常交易！

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

Answer 3

在命令模式中，命令对象知道能够完成给定请求的人。或者它也可能知道谁是所有需要的人，以完成请求。 （例如：如果请求是＆＃34;洗涤＆＃34 ;,命令对象得到衣服，找到洗衣机，放洗涤剂，旋转机器并完成过程。对于这些动作，它可以打电话给其他人（对象）。

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

Answer 4

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