要使用多线程，Command模式比Decorator模式更有用吗？

Question

看过在前一个项目中如何使用Command pattern，我可以理解它在多线程（并行）编程中是如何有用的，因为命令可以在不同的线程中执行。当需要在命令之间传递数据时，数据可以存储在共享内存中，并且可以将该数据的指针（或句柄）传递给不同线程上的调用者。

然而，Decorator模式似乎有限制，一切都必须在一个线程上发生，因为装饰器必须直接调用委托，暗示它们必须在同一个线程上。

我对此限制的理解是否正确？相反，是否可以在多个线程上运行装饰器？

---

我正在尝试实现的是一个处理数据流的管道。

• 要实现为Command模式，其execute方法将采用两个参数：输入缓冲区和输出缓冲区。
• 要实现为Decorator模式，其getdata方法将调用其委托来获取上一步的结果，应用自己的处理，并将结果返回给调用者。

然而，在我以两种风格实现它之后，我发现每种风格都有一些我最初不清楚的限制。

• 使用命令模式时，我可以通过使用新缓冲区开始接受更多输入数据，而早期缓冲区正由一些在不同工作线程中运行的命令处理。我似乎无法用Decorator模式做到这一点。
• 使用Decorator模式时，装饰器可以对其委托进行任意数量的调用，并能够将结果合并到一个块中。它还可以通过发出一个大请求来分割数据，缓存它，然后返回它。当我使用带有一个输入缓冲区和一个输出缓冲区的Command模式时，不能有任何组合或分割结果。

Answer 1

是否可以在任何线程上运行装饰器是实现定义的：）

如果你的装饰者是线程安全的......是的。如果不是：添加同步。这可能会破坏您的表现。

然而，在我看来，装饰者大部分时间都在使用他们正在装饰的对象，并且只有少量的上下文/状态。在这里装饰的对象，显然应该是线程安全（或意识到），或者即使没有装饰器它也会有同样的问题。

也许这就是你所谓的“轻量级”装饰者。如果你的装饰者是重量级的（因为他们'使用世界'来完成他们的工作），肯定会需要同步。这甚至可能导致性能瓶颈。

但是从根本上 没有什么能阻止（通常）装饰器在你想要的任何线程上执行。