轉自：http://blog.csdn.net/ithzhang/article/details/52983530

上次插件進程化分享時，感覺大家對面向對象思想的理解還停留在很基礎的層次。面向對象思想確實很難理解，因此學習面向對象思想并非一日之功。我看過很多面向對象的書，包括OOA、OOD、設計模式、UML、架構設計等，因此對于面向對象思想有了一些自己的淺顯的理解，希望能對大家理解面向對象有所幫助。由于僅僅處于入門階段，很多東西理解并不是那么透徹，可能存在很多錯誤或理解不夠準確的地方，希望各位能指出來大家共同進步。

面向對象的東西很多，因此打算分多次介紹。這次主要介紹一些基礎概念，后面如果有機會再跟大家進一步的討論面向對象跟深入的東西。

這次主要關注以下四個方面：

1.?????? 面向對象為什么那么難？

2.?????? 類和對象是從石頭里蹦出來的么？

3.?????? 設計模式有那么重要么？

4.?????? UML和面向對象什么關系？

首先我們來看下為什么面向對象那么難。很多科班出身的程序猿，當然也包括我。第一門編程語言學習的是C語言。眾所周知，C語言是一門面向過程的語言，在編寫復雜的C程序時，用的最多的就是流程圖和偽代碼。只要使用流程圖詳細描述出程序的每一步，就可以很容易的照貓畫虎將流程圖轉換成C代碼。這也是C語言這類面相過程語言的特點，講究自頂向下逐步求精。任何系統，只要找到它的入口，從入口開始，詳細分析它的每一步以及影響這一步的所有因素，然后順藤摸瓜，直至分析完整個系統。

很多人的思維被面向過程先入為主，每次拿到一個需求時，都會強迫自己去分析所有的流程。小的系統還好，如果一個相對復雜的系統，流程眾多且復雜、參與者眾多，這個時候嘗試去分析其中的每一步，經常會遇到陷入業務細節的泥潭無法自拔的問題。而面向對象思想的出現就是為了解決這類復雜的問題。

面向過程存在的另一個問題是，整個系統的分析是順序的，下一步依賴上一步的分析結果。如果上一步不穩定或存在問題，以后就死翹翹了。我們經常說瀑布式軟件開發過程存在問題，大力提倡敏捷，一個很重要的原因是：瀑布式開發過程太過依賴上一步的結果，一旦上一步存在問題，后面將會全盤皆輸。這是不能令人接受的。

C++這門編程語言，既支持面向對象又支持面向過程。因此我們在實現一個東西時，既可以這樣做又可以那么做。過多的選擇反而讓我們無所適從。有時候我們經常會想明明加一個else、case或者在一個方法里實現的問題，為何要使用那么多類來實現。這不是多此一舉嗎。有些時候確實是多此一舉。但面向對象語言存在的目的就為了構建可維護、可擴展、靈活性好的系統?？删S護、可擴展和可維護聽起來很高大上，但是只是飄在天上的遙遠關鍵詞，好像在我這里無法落地。無法落地的原因就是你還沒有真正理解什么是面向對象。

面向對象關注類、對象以及對象間的交互。再復雜的系統，都是由相互獨立的對象通過一定的交互和協作來完成。就像現實中大家協作完成一件事情一樣，每個人各司其職，既相互獨立又關系密切。而所謂的面向對象的系統，就是我們的系統有很多相互獨立的對象。每個對象具有一定的職責，對象之間相互交互或協作。整個軟件系統就是靠這些眾多對象之間的交互來運作。

但是這些對象或類是如何產生的。是從石頭里蹦出來的么？很多時候大家在介紹自己的設計時，會說我覺得這里應該有一個類，它有XX職責，然后跟XX是什么關系，它們進行交互。當問他為何要有這樣一個對象時，好像也說不太清楚，只能告訴你是通過多年的經驗分析出來的，等你到我這個年紀也會明白，然后留下無助的你繼續迷茫，還是不懂為何要在這里安置這樣一個類。經驗這個東西的最大特點就是不能復制和驗證。別人的經驗只能保證他的設計，而無法有效指導你進行設計，別人的經驗也無法給出詳細的推導，也就無法驗證其正確性。

其實這些類和對象是可以依據一定的規則推導出來的。OOA（面向對象分析）和OOD（面向對象設計）就是叩開面向對象大門的金鑰匙。通過OOA、OOD我們發現和描述對象、定義對象的職責、描述對象間的交互等等。

?

大家在聽到某某在說，我這里用了XX設計模式，解決了什么問題。比如上次在插件進程化分享時，我提到過用了模板方法模式，解決了進程化協議構造的問題。很多初學者聽別人說到過設計模式很重要，但是卻不明白為什么設計模式如此重要。設計模式是計算機大牛們在編程時，針對某些特定問題總結出來的一套經驗。經典設計模式有23種，后來又慢慢擴展越來越多。學會前人的這樣經驗固然重要，但是卻沒有想象中的重要。沿著前人的車轍，固然可以讓我們少走彎路，但更要的是學會前人分析解決問題的思路。大家可以看到每種設計模式在介紹時，都會有一個前提，即這個模式在XX情況下適用，可以解決什么問題，有什么樣的副作用。所以每種設計模式都有自己的適用背景，平時使用時如果不考慮這些背景以及導致的副作用，經常會出現得不償失的效果。很多人都很苦惱的是為何我看了那么多的設計模式，卻仍然無法將設計模式應用到我的工作中去。對設計模式沒有那么了如指掌是一方面的問題，但更重要的是經典的設計模式背景太過純粹，而我們的所面臨的背景相對復雜。有些時候這些設計模式是不能那么輕而易舉原封不動的照搬過來。因此工作中經常遇到的就是我們使用的設計模式并不是純粹的XX設計模式，而是基于它的改進或變體或者是幾種設計模式的混用。設計模式是面向對象思想的很好的體現，應用了設計模式的系統，具備很好的靈活性。對象之間解耦合，內聚性強。很容易擴展和修改。應用設計模式的設計良好的系統，后面維護起來也很容易，不像我們的代碼出現越維護越糟糕，這里一句if那里一句magic code，類、方法變得臃腫，職責越來越不清晰、分支越來越多，圈復雜度越來越高，四處有重復代碼。讀起來都費勁，更別提基于此繼續修改了。

設計模式也是基于面向對象思想總結出來的，因此比掌握設計模式更重要的是學會面向對象的思想。當你達到一定的高度，你也可以創造屬于自己的設計模式。因此比掌握某個設計模式更重要的是學會面向對象的思想，哪怕沒有應用任何設計模式，也一樣可以構造出好的面向對象的代碼。

UML （Unified Modeling Language）統一建模語言。 是一種可視化的建模語言。用來描述需求、設計。方便參與軟件系統構建的各方交流溝通。

如果有人跟你說學好UML你就學會了面向對象，你可千萬不要相信他。

就像學會英語這門外語并不能保證你口若懸河出口成章字字珠璣一樣。學會UML只是讓你有了可以表達和描述你的設計的工具。UML只是和面向對象更配哦。

現在軟件分工越來越細，需求分析、建模、設計、實現往往有很多人參與，UML的出現方便了各方的交流溝通。使用各種圖來描述系統，比文字更有清晰直觀，結合文字描述更容易理解。

UML包括九種圖：用例圖、類圖、對象圖、狀態圖、序列圖（順序圖）、協作圖（通信圖）、活動圖、構件圖、部署圖。最常用到的圖是用例圖、類圖、序列圖

從上面大家可以看到，UML并不包括流程圖。流程圖這個東西是面向過程時代的產物。它有一個致命的缺陷就是只描述了流程，卻無法給出有哪些對象參與以及對象間的協作。UML定義了活動圖用于替代流程圖，活動圖中引入了泳道的概念，泳道即代表每一個參與的對象。因此推薦大家在寫概要設計文檔時避免使用流程圖，而應該使用活動圖。概要設計使用流程圖，只是描述了業務流程，并沒有進行任何設計。流程圖描述的客戶業務流程應該在更早一些的產品需求文檔里體現。

UML不僅僅可以在設計階段使用，還可以應用在需求階段。需求分析階段使用用例圖、用例文本描述整個系統的功能范圍。設計階段使用類圖說明類之間的靜態結構關系、使用序列圖說明類之間的交互順序、使用活動圖描述復雜業務流程。

???????? 第一次分享不準備寫太多，有些關鍵詞先讓大家混個耳熟吧，后面再給大家詳細介紹！

?????????????????? 關于面向對象和面向過程的本質區別，其實并不僅僅局限上面的那些，那么它們的本質區別是什么呢？下次再跟大家分享。

總結

以上是生活随笔為你收集整理的关于面向对象的理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。