把這兩個概念放在一起，確實不是很工整。但對於熱衷設計的我們，只要有用就行。
首先來解釋這兩個概念。 OO是什嗎？呵呵,可能大家會笑我，OO誰不知道？不要和我說什麼封裝/繼承/多態！這些都是所謂的特性，我的問題是：OO到底在做什麼呢？ 我給大家打個比方，假設你是一個項目的專案經理。現在你手頭上有一個任務，需要你去完成。你會怎麼去做呢？ 一個選擇，是你自己完成所有任務。當然，如果你願意奪取你所有的手下的機會的話。你是可以完成。這就是我們以往經常說的面向過程（OP）。你知道所有你該做的，並且你去做了。 當然，你慢慢會發現，你的手下可以協助你解決一些問題。於是你試圖讓他們去執行你安排給他們的任務。不過，你並沒有脫離OP的階段，所有的工作都是你在安排，你在策劃，你在考慮。你只是使用了一些現成的庫來協助你工作。 隨著時間的推移，你的手下開始慢慢能頂替你的工作。你開始將任務直接交給幾個手下，告訴他們你想要的結果，讓他們放手去幹。過程中進行適當的監督和協調。恭喜你，你在採用物件導向了。你不再關心實現任務的具體細節。你關注的是手下工作要開心，調節他的工作狀態，適當給些鼓勵，適當給些壓力，適當給些激勵。這就是OO。 是的，OO是處理問題的方式。把你從無所不知的聖人，落地為毫無能力的蠢才。選擇OP還是OO，只是你的性格而已。 那麼，解釋完OO後，我們再來解釋一下“事件”這個概念。 什嗎？事件？不就是函數類型嗎？不就是以前Windows下的回掉函數嗎？不就是一個特殊類型的指標嗎？函數指標。 是的，我的問題同樣不是問事件是如何?的。我是問，事件是做什麼的？ 在給你做一個比方吧。比方說我們要完成一個任務。內容是從北京到南京，距離1000公裡。我們選擇的工具是汽車，路線是高速公路。很好，你開始要選擇開什麼車了。現在市面上有現成的各種品牌的車（這些都是架構提供的現成類，如果用了，你就不需要自己再去實現汽車類了）。你願意選用嗎？可是現在有一個很現實的問題，家用車一般的油箱只有50升，要跑完1000公裡，油肯定不夠。看來一般的車是滿足不了我們的需求了。 一個辦法是我們自己造一個車，油箱足夠大，能夠放120升油。那麼顯然動力系統就能夠滿足。不過可想而知，要造一個車可是需要很多專業知識的。這條路你基本走不通，所以你只能又轉向原來的方案。 既然一次不夠，可不可以加油？當然可以！ 好了，這個時候，我們要注意一下，我們在談論“事件”這個概念，現在才剛剛開始。 對於我們要完成任務的這些人來說，“事件”並不是我們關注。真正關心的人，是那些設計汽車和高速公路的人。 好吧，現在我們要做一個艱難的轉變。你由完成任務（從北京到南京）的人，轉變為公路系統的總設計師了。等你轉變完這個角色變換後，恭喜你，你的設計把控能力又提升了一大步。 假設你已經轉換完成。你現在是公路系統總設計師。你在設計道路的同時，當然要解決好我們加油的問題。可是你並不知道我們什麼時候需要加油。怎麼辦呢？ 首先必然要在高速公路上設計必要的加油站，然後更重要的是在公路上提出標誌，讓汽車能夠接受到資訊，知道什麼地方有加油站。 回到軟體上來，如果你設計的高速公路類，還有汽車類，那麼汽車類應該在接受到高速公路上的加油站資訊的時候，就會觸發一個事件。至於怎麼處理，那就是任務完成者，也就是駕駛員要判斷的了。首先看看油還夠不夠了，如果不夠了，就進站加油。 饒了這麼大的一圈，我就是想說，事件是架構設計者，讓使用者方便擴充或定製自己行為的方式。 我之所以將EOD和OOD這兩種方式放在一起討論，其實也是因為目前的流行架構都是兩者的結合。如MFC、VCL、.NET Framework。 最近在討論Eclipse架構的時候，討論到它的外掛程式的“擴充點”概念。其實事件也是設計中使用的“擴充點”。或者可以說，EOD是OOD的擴充點。 Event並不是OO本身所特有的。是為瞭解決“執行流程”問題，在OO的基礎上加上的思想。有了這個思想，才讓我們這些使用者可以方便實現各種需求。 以往總聽到OP和OO的爭論，其中心都是理念的爭執！其實，真正解決問題的時候，我們經常什麼都用！可能那個時候我們才發現，什麼思想不思想，能解決問題的就是好的。這也讓我們更加相信設計沒有邊界！
