c# - 发布者/订阅者的使用陷入​​有状态

Question

这是我目前挂断的一般设计问题。它导致了一些心理代码块......如果它只是一个常见的陷阱，我不想继续这样，但如果它被接受使用，我想继续，因为代码非常干净并且解耦(除了横切消息)。

我在代码中有一个基于列表的发布者/订阅者模式，我使用它允许任意代码部分发送未知订阅者可以收听的消息。非常坦率的。

我目前使用此模式的一个用例是启动一个 UI 状态指示器，向用户显示应用程序正忙。工作开始前有消息，进度有重复消息，完成有消息。看起来很干净，较低级别的代码只发布消息而不关心听众。

起始消息最初驱动 UI；它在主窗体的状态栏中显示一个字幕进度条。完成消息隐藏了这个进度条。更新消息在标签中表示为文本。

当时我没有意识到，我让 UI 依赖于这些消息的顺序。 UI 依赖于开始和完成消息才能正确反射(reflect) UI。我所指的“有状态”是在订阅者端(消息本身不保留任何状态)。

这种用法是否违反发布/订阅模式？如果是这样，问题是对消息顺序的依赖吗？如果没有，那很好，我可以继续:-)

Answer 1

在您的示例中，sequential coupling代码气味可能来自您的订阅者对发布者的内部运作了解太多(即，当一个开始时，另一个开始)。

您可以通过减少消息中的信息或让订阅者不利用消息的时间序列来降低耦合度。

例如，让订阅者对开始和进行中的消息执行相同的例程，将消息的分辨率降低为“WORKING”。如果需要，UI 订阅者可以生成对话框，或者如果它已经存在则更新它。管理对话框的生命周期是 UI 订阅者的工作，而不是应用程序的。

但是，这种细微的气味可能不足以开始混淆应用程序和 UI 订阅者之间的消息。

或者，您可以让订阅者足够健壮，无论调用的消息顺序如何，都能做正确的事。开始，开始，处理，结束，处理，开始，等等。订阅者的责任应该是管理进度对话框......无论应用程序发出什么疯狂的消息，都要尽力而为。