這是一個我目前掛斷的通用設計問題。它導致了一些精神代碼塊...我不想像這樣繼續它，如果它只是一個常見的陷阱，但我想繼續，如果它被接受的用法，因爲代碼很乾淨，去耦（禁止交叉信息）。發佈者/訂閱者使用情況滑入狀態
我在代碼中有一個基於列表的發佈者/訂閱者模式，用於允許任意代碼段發送未知用戶可以收聽的消息。非常坦率的。
此模式的當前用例之一是創建一個UI狀態指示器，顯示用戶應用程序正忙。工作開始前有一條消息，一條重複的進度消息和一條完成消息。它看起來很乾淨，較低級別的代碼只發布消息並且不關心聽衆。
起始消息最初驅動UI;它會在主窗體的狀態欄中顯示一個選取框進度條。完成消息隱藏了這個進度條。更新消息在標籤中表示爲文本。
當時沒有意識到，我使UI取決於這些消息的順序。用戶界面依賴於開始和結束消息來正確反映用戶界面。我所指的「狀態」在用戶端（消息本身不保留任何狀態）。
這種用法違背了pub/sub模式嗎？如果是這樣，問題依賴於消息順序？如果沒有，那麼好，我可以繼續:-)
在您的示例中，sequential coupling代碼氣味可能來自您的訂閱者，因爲他們太瞭解發佈者的內部工作原理（即一個啓動時，另一個啓動時）。
您可以通過減少消息中的信息或使用戶不利用消息的時間順序來減少耦合。
例如，讓訂戶對開始消息和進行消息執行相同的例程，從而將消息的分辨率降至「正在工作」。如果需要，UI訂閱者可以產生對話框，或者如果它已經存在，則更新它。 UI用戶的工作是管理對話框的生命週期，而不是應用程序的生命週期。
但是，這種小氣味可能不足以啓動應用程序和UI訂閱者之間的消息的卷積。
或者，您可以讓您的訂閱者具有足夠的可靠性，以執行正確的事情，而不管被調用的消息的順序如何。開始，開始，處理，結束，處理，開始等等。訂閱者的責任應該是管理進度對話框......以盡最大可能無論發送什麼瘋狂的消息。
我同意代碼氣味。我已經意識到耦合啓動/停止是問題，並且會將其重構爲UI關注點。 – 2012-02-16 08:19:23
我認爲這是可以的一般的酒吧/子模式。
但你有沒有考慮過如何處理嵌套調用？
假設您有出版商三個電話：）））
如果我理解你，你會扔開始/ INPROGRESS /每次通話結束消息。如果GetFullName（）在內部調用其他兩個調用來構造消息的全名：
begin（全名） - begin（first name） - end（first name） - begin（last name） - end（姓氏） - 結束（全名）。
因此，一個GetFullName（）調用的進度條閃爍。
您是否考慮過這種情況？也許你可以使用一個計數器，但然後是什麼與例外，防止呼叫結束消息...
UI在一系列末尾的最後一次結束呼叫中保留了一個呼叫計數，它隱藏了狀態欄。這實際上是我不確定的事情的一個例子。這種對信息鏈的依賴使我有理由重新思考。目前爲了處理異常，消息的發佈者確保通過try-finally或using塊發佈結束消息。 – 2012-02-15 15:46:58
Try-finally聽起來不錯。如果您在實施該功能時告訴我們您關於該功能的體驗，我會很高興。 – brgerner 2012-02-15 16:03:44
經過反思，我認爲對消息模式的依賴比我當前的實現更多的是Message Bus，我選擇重構模式依賴關係。 – 2012-02-16 08:21:40
我分享你的「東西似乎不對」的感覺。
您是否應該能夠在不涉及UI的情況下執行發佈者？我懷疑是這樣。用戶界面可能會啓動我想要的事情，但事實上，您知道發佈商的內部工作 - 發佈商處於「開始」，「中間」和「結束」狀態 - 是一種代碼味道。
也許UI應該只是另一個用戶。訂閱「主題」（使用pub/sub terminology）應該是「processProgress」，並且發佈者本身會在特定方法內發送反映該消息的消息。發佈者的OR some other class that is controlling the execution將調用發佈者來發送開始/中間/結束消息。
根據收到的消息，UI將決定顯示進度條和顯示的消息。
我同意代碼氣味。我將根據啓動和停止的方式將消息的生命期從消息中分離出來，而不是從UI中完全驅動。 – 2012-02-16 08:18:30
聽起來不可怕，回到你的代碼哥們！ :) – kenny 2012-02-15 15:36:29
如果消息出現亂序會發生什麼？ – cadrell0 2012-02-15 19:14:10
@ cadrell0它可能無法啓動或一旦顯示可能無法關閉...我的質疑解決方案的來源。 – 2012-02-16 08:17:25