事件驅動機制跟消息驅動機制相比，有哪些優劣的地方？

01-09

事件模式耦合高，同模塊內好用；消息模式耦合低，跨模塊好用。事件模式集成其它語言比較繁瑣，消息模式集成其他語言比較輕鬆。事件是侵入式設計，霸佔你的主循環；消息是非侵入式設計，將主循環該怎樣設計的自由留給用戶。如果你在設計一個東西舉棋不定，那麼你可以參考win32的GetMessage，本身就是一個藕合度極低的介面，又足夠自由，介面任何語言都很方便，具體應用場景再在其基礎上封裝成事件並不是難事，介面耦合較低，即便哪天事件框架調整，修改外層即可，不會傷經動骨。而如果直接實現成事件，那就完全反過來了。

push和pull的區別，看情況使用。

windows上面搞出來的這個區別。事件比消息封裝的更高一層。

我是這麼理解的

假設系統是這樣的：處理A事後還有B事要處理

告訴處理A事的程序B事是如何做的，在A事處理完後，直接調用處理B事的程序（或介面）來處理B事。這是基於事件的。

處理完A事，放個消息在某個地方，意思是我處理完A事了，此時，處理A的程序已經完事大吉了。至於何時，如何處理B事，由另一個程序根據那個消息來處理。這就是基於消息的。

沒有區別。個人感覺說法上有點區別。

基於事件，給人感覺實時性要高點。很多小的框架是用函數回調來做。不過也有非同步事件這個說法，本質上就是消息了。

基於消息都是非同步。好像沒聽過同步消息這個說法。

其實兩者本質上是一樣的。

如果你做過windows界面和java界面開發的話，應該發現兩者其實是一樣的。在windows中是消息機制，java中是事件機制。

其實我們通常說的事件，範圍比較大，是指某個事情的發生，我們稱之為事件。在編程中事件，其實就是相當於一個消息。觸發了一個事件，說的其實就是觸發了一個消息/產生一個消息。java中是Event， windows中是msg，其實兩者本質上是一樣的。而且，都是觀察者模式。

如果明白了觀察者模式，應該就能理解我說的，事件和消息其實是一個意思。

從寫法上來看一個是同步，一個是非同步

有點像SendMessage和PostMessage的區別

我以為是炒股的問題。

消息驅動容易讓程序死掉。就是我們經常看到的程序界面變白。

應該這麼問，消息隊列和事件觸發的區別，本質是沒啥區別的

這兩者難道不一樣？

事件驅動和消息驅動就像dependency injection和service locator，有各自的適用場景。具體我也說不清楚，反正好的隱喻很重要。

考慮這個沒啥實踐意義，除非搞理論研究，或寫論文啥的，累

這兩個有區別？