轉(zhuǎn)自：http://blog.csdn.net/ithzhang/article/details/52983530

上次插件進程化分享時，感覺大家對面向?qū)ο笏枷氲睦斫膺€停留在很基礎的層次。面向?qū)ο笏枷氪_實很難理解，因此學習面向?qū)ο笏枷氩⒎且蝗罩ΑＮ铱催^很多面向?qū)ο蟮臅?#xff0c;包括OOA、OOD、設計模式、UML、架構設計等，因此對于面向?qū)ο笏枷胗辛艘恍┳约旱臏\顯的理解，希望能對大家理解面向?qū)ο笥兴鶐椭Ｓ捎趦H僅處于入門階段，很多東西理解并不是那么透徹，可能存在很多錯誤或理解不夠準確的地方，希望各位能指出來大家共同進步。

面向?qū)ο蟮臇|西很多，因此打算分多次介紹。這次主要介紹一些基礎概念，后面如果有機會再跟大家進一步的討論面向?qū)ο蟾钊氲臇|西。

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

1.?????? 面向?qū)ο鬄槭裁茨敲措y？

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

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

4.?????? UML和面向?qū)ο笫裁搓P系？

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

很多人的思維被面向過程先入為主，每次拿到一個需求時，都會強迫自己去分析所有的流程。小的系統(tǒng)還好，如果一個相對復雜的系統(tǒng)，流程眾多且復雜、參與者眾多，這個時候嘗試去分析其中的每一步，經(jīng)常會遇到陷入業(yè)務細節(jié)的泥潭無法自拔的問題。而面向?qū)ο笏枷氲某霈F(xiàn)就是為了解決這類復雜的問題。

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

C++這門編程語言，既支持面向?qū)ο笥种С置嫦蜻^程。因此我們在實現(xiàn)一個東西時，既可以這樣做又可以那么做。過多的選擇反而讓我們無所適從。有時候我們經(jīng)常會想明明加一個else、case或者在一個方法里實現(xiàn)的問題，為何要使用那么多類來實現(xiàn)。這不是多此一舉嗎。有些時候確實是多此一舉。但面向?qū)ο笳Z言存在的目的就為了構建可維護、可擴展、靈活性好的系統(tǒng)。可維護、可擴展和可維護聽起來很高大上，但是只是飄在天上的遙遠關鍵詞，好像在我這里無法落地。無法落地的原因就是你還沒有真正理解什么是面向?qū)ο蟆?/span>

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

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

其實這些類和對象是可以依據(jù)一定的規(guī)則推導出來的。OOA（面向?qū)ο蠓治?#xff09;和OOD（面向?qū)ο笤O計）就是叩開面向?qū)ο蟠箝T的金鑰匙。通過OOA、OOD我們發(fā)現(xiàn)和描述對象、定義對象的職責、描述對象間的交互等等。

?

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

設計模式也是基于面向?qū)ο笏枷肟偨Y出來的，因此比掌握設計模式更重要的是學會面向?qū)ο蟮乃枷搿．斈氵_到一定的高度，你也可以創(chuàng)造屬于自己的設計模式。因此比掌握某個設計模式更重要的是學會面向?qū)ο蟮乃枷?#xff0c;哪怕沒有應用任何設計模式，也一樣可以構造出好的面向?qū)ο蟮拇a。

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

如果有人跟你說學好UML你就學會了面向?qū)ο?#xff0c;你可千萬不要相信他。

就像學會英語這門外語并不能保證你口若懸河出口成章字字珠璣一樣。學會UML只是讓你有了可以表達和描述你的設計的工具。UML只是和面向?qū)ο蟾渑丁?/span>

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

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

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

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

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

?????????????????? 關于面向?qū)ο蠛兔嫦蜻^程的本質(zhì)區(qū)別，其實并不僅僅局限上面的那些，那么它們的本質(zhì)區(qū)別是什么呢？下次再跟大家分享。

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。