為了表明我不是標題黨，我得先亮出這 10 行程式碼：

class Event:
    handlers = dict()

    def attach(self,handler_id,handler):
        if not callable(handler):
            raise TypeError('handler object is not callable')
        self.handlers.update({handler_id: handler})

    def notify(self):
        return [handle_func() for
 
 _,handle_func in self.handlers.items()]
複製程式碼

有的童鞋可能笑了，就這 10 行程式碼，連個類例項和方法呼叫都沒有，能幹嘛？首先，你要知道我為了這 10 行程式碼，我把所有註釋都刪了，其次，你是對的，所以請看下面的程式碼（陰險.jpg）：

def update_cache(**kwargs):
    print('<update_cache>')

def send_notification(**kwargs):
    print('<send_notification>')

if __name__ == '__main__'
 
:
    order_completed_event = Event()
    order_completed_event.attach(handler_id='update_cache',handler=update_cache)
    order_completed_event.attach(handler_id='send_notification',handler=send_notification)
    order_completed_event.notify()
複製程式碼

這玩意兒是啥？

有的童鞋可能看出來了，這是一個簡易的事件元件（不同程式語言、框架叫法不一樣），也可以說是觀察者模式的一種簡單實現。

觀察者模式是軟體設計模式的一種。在此種模式中，一個目標物件管理所有相依於它的觀察者物件，並且在它本身的狀態改變時主動發出通知。這通常透過呼叫各觀察者所提供的方法來實現。此種模式通常被用來實時事件處理系統。——維基百科

要怎麼用？

簡單解讀一下上面的示例程式碼：

• 例項化一個 訂單完成事件
• 往這個事件註冊 更新快取 和 傳送通知 處理器
• 然後直接呼叫事件的 notify 方法，執行所有已註冊的處理器，最後返回所有處理器的執行結果

示例程式碼中的業務邏輯，是我抽象的一個大家都比較容易理解的業務場景，當一個訂單完成後，一般除了訂單本身的主流程之外，多多少少都需要執行一些和訂單主流程關係不大的邏輯，例如順便更新點什麼東西或是通知一下買家/賣家，這麼說，現在只需要在訂單完成的時候，呼叫一下 訂單完成事件 的 notify 方法，就可以完成相關的邏輯了。

為什麼要用？

在很多專案中（起碼我見過的），大多都會把上述提到的跟訂單主流程關係不大的邏輯寫在訂單主流程後，或是把業務服務放在那兒進行呼叫，而這麼做，程式碼會越來越臃腫，維護起來也不方便，有強迫症的人看著也不舒服，這一切都是因為邏輯的耦合導致的，而我們可以用上面的事件元件進行優化，達到邏輯的解耦，讓程式更容易維護。

你可以不用造輪子

本文的例項程式碼，只是一個極其簡單的輪子，甚至連輪子都說不上，寫這麼一個示例只是為了讓大家能大致明白實現的原理。現流行的語言/框架，幾乎都有提供對應的元件：

• Django - Signals
• Symfony - EventDispatcher Component
• Laravel - Events
• Spring - Events

總結

雖然我只是寫了 10 行程式碼，但希望這 10 行程式碼能給你一點優化程式碼的靈感。