面向對象、面向服務、面向組件三種編程模式有什麼區別？分別適用於哪些領域的開發？

---

三個數據後面都缺了一個詞，分別是：「編程」、「架構」和「開發」(或「軟體工程」)。 同時，不是「面向」組件而是「基於」組件。

• 面向對象編程(Object-Oreinted Programming) 是一種編程範式。指在設計程序時大量運用類實例對象的方式。OOP一旦在項目中被運用，就成了時刻要考慮的東西。
• 面向服務架構(Service-Oreinted Architecture) 是將軟體設計成一組可互操作的服務的一套原則或方法論。通常在考慮系統架構時才會觸及SOA。
• 基於組件開發(Component-Based Development) 是一種軟體工程實踐，設計時通常要求組件之間高內聚，松耦合。其介面可能是OO的，調用方式可能是以Service的方式。基於組件開發關注系統層次、子系統邊界和子系統間通訊的的設計，處於代碼層面但不像OOP的一樣是時刻需要運用的東西。

三者身處軟體開發的不同層面，因此說他們用於「哪些領域」並不恰當。不論是哪個領域的軟體開發，都可能要同時面對OOP、SOA和CBD。

---

無論什麼系統變大了之後，就會有一系列問題。

面向XX就是為了解決系統成長過程中遇到問題，而採用的一些範式。

舉例來說：你開始給一個企業做MIS系統。

當這個企業來很小的時候，用簡單的面向對象編程，資料庫+服務端+瀏覽器已經滿足需求。不需要考慮面向組件開發和SOA.

慢慢的，這個企業長大了，當初簡單的mis系統，變得越來越複雜和龐大。系統中有很多重複功能的代碼。當這些功能模塊的業務有變化時是你頭疼的時候：代碼中有很多地方要修改，遇到新員工，有時總是改不全。系統上線問題越來越多，需求響應時間也越來越長。經常被客戶罵：他X的，這麼簡單的需求搞了半個月都上不了線。去年xxxxxxx兩天就上線了。

此時，你會考慮怎麼把系統中那些重複的代碼統一起來。你會考慮到組件化，即「面向組件」。你把一個個比較獨立的業務模塊約定好介面，開發成組件。以後再有類似的功能模塊，直接調用這個組件，即節省開發成本，又容易維護。

後來，企業變成了集團公司。已經上線了很多套各種各樣的mis系統。雖然大部分系統都實現了組件化。但做為一個集團公司，仍然有很多共同的業務，不同mis系統中有很多功能重複的模塊。此時又面臨業務升級困難，難以使用的問題：一個需求可能要涉及很多套mis系統的升級。同時每套系統都有獨自的界面，客戶錄入一個數據，要打開N個頁面，要登陸N次，叫苦不迭。各種數據不一致的問題接踵而來。

SOA來啦。架構師把各個系統功能類似的模塊抽象成服務，重複的模塊再也沒有了，不同系統間互相調用服務介面。以前要自己寫一大堆代碼，現在搞清楚介面，直接調用另一套Mis系統的服務介面就 OK了。也有了單點登陸，有了portal，有了搜索服務，有了知識庫等等。

但是問題又來了：

總有一些很重要的服務，所有的系統都會依賴它，它出一點問題，所有系統都停轉。你開始考慮雙機，熱備，負載均衡。

以前用的IBM的主機+Oracle資料庫+EMC的存儲，再後來買更貴的性能更好的。慢慢的你發現，企業掙的錢都他媽的給了IOE。你開始考慮分散式，開始考慮使用開源產品。

先寫到這兒。

---

面向過程、面向對象、面向組件、面向服務，這些都是解決問題的一種思維模式和執行方法，都強調「面向」是因為它們解決問題的出發角度不同。

把一個問題看成過程，就可以用面向過程的思想來解決。

把一個問題看成對象，就可以用面向對象的思想來解決。

把一個問題看成組件，就可以用面向組件的思想來解決。

把一個問題看成服務，就可以用面向服務的思想來解決。

區別是它們從不同角度解決不同問題的效率。

對於它們，你可以簡單理解成包含關係或大小問題，取決你從哪個層面看。

我無意長篇大論，舉個實例：

我現在嘗試用它們解決你的這個問題本身來解釋你的困惑。

面向過程：提出問題，回答問題，獲得答案。

面向對象：你提出你的問題，我回答你的問題，你獲得我的答案。

面向組件：你用中文提出問題，我用中文回答你的問題，你獲得我用中文回答你的答案。

面向服務：你在知乎用中文提出問題，我在知乎用中文回答你的問題，你獲得我在知乎用中文回答你的答案。

我無意像【安江澤】那樣回答你的問題，是因為我雖然知道你的這個問題屬於「軟體編程」領域，但我嘗試用不同的角度看你的問題，我用這個回答提醒你：

「它們」不僅僅用來解決「軟體編程」、「系統架構」等領域的問題，還能用來解決更廣泛的領域。

但願你能看得清、聽得懂、想得透。

---

推薦閱讀：