為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??

前言

此文譯自CodeProject上<How I explained OOD to my wife >一文，該文章在Top Articles上排名第3，讀了之后覺得非常好，就翻譯出來，供不想讀英文的同學參考學習。

作者(Shubho)的妻子(Farhana)打算重新做一名軟件工程師(她本來是，后來因為他們孩子出生放棄了)，于是作者就試圖根據(jù)自己在軟件開發(fā)設(shè)計方面的經(jīng)驗幫助她學習面向?qū)ο笤O(shè)計(OOD)。

自作者從事軟件開發(fā)開始，作者常常注意到不管技術(shù)問題看起來多復(fù)雜，如果從現(xiàn)實生活的角度解釋并以對答的方式討論，那么它將變得更簡單。現(xiàn)在他們把在OOD方面有些富有成效的對話分享出來，你可能會發(fā)現(xiàn)那是一種學習OOD很有意思的方式。

下面就是他們的對話：

OOD簡介

Shubho :親愛的，讓我們開始學習OOD吧。你了解面向?qū)ο笤瓌t嗎？

Farhana :你是說封裝，繼承，多態(tài)對嗎？我知道的。

Shubho :好，我希望你已了解如何使用類和對象。今天我們學習OOD。

Farhana :等一下。面向?qū)ο笤瓌t對面向?qū)ο缶幊?OOP)來說不夠嗎？我的意思是我會定義類，并封裝屬性和方法。我也能根據(jù)類的關(guān)系定義它們之間的層次。如果是，那么還有什么？

Shubho :問得好。面向?qū)ο笤瓌t和OOD實際上是兩個不同的方面。讓我給你舉個實際生活中的例子幫你弄明白。

?再你小時候你首先學會字母表，對嗎？

Farhana :嗯

Shubho :好。你也學了單詞，并學會如何根據(jù)字母表造詞。后來你學會了一些造句的語法。例如時態(tài)，介詞，連詞和其他一些讓你能造出語法正確的句子。例如：

"I" (代詞) "want" (動詞) "to" (介詞) "learn" (動詞) "OOD"(名詞)。

看，你按照某些規(guī)則組合了單詞，并且你選擇了有某些意義的正確的單詞結(jié)束了句子。

Farhana :OK，這意味著什么呢？

Shubho :面向?qū)ο笤瓌t與這類似。OOP指的是面向?qū)ο缶幊痰幕驹瓌t和核心思路。在這里，OOP可以比作英語基礎(chǔ)語法，這些語法教你如何用單詞構(gòu)造有意義且正確的句子，OOP教你在代 碼中構(gòu)造類，并在類里封裝屬性和方法，同時構(gòu)造他們之間的層次關(guān)系。

Farhana :嗯..我有點感覺了，這里有OOD嗎？

Shubho :馬上就有答案。現(xiàn)在假定你需要就某些主題寫幾篇文章或隨筆。你也希望就幾個你擅長主體寫幾本書。對寫好文章/隨筆或書來說，知道如何造句是不夠的，對嗎？為了使讀者能更輕 ? 松的明白你講的內(nèi)容，你需要寫更多的內(nèi)容，學習以更好的方式解釋它。

Farhana :看起來有點意思...繼續(xù)。

Shubho : 現(xiàn)在，如果你想就某個主題寫一本書，如學習OOD，你知道如何把一個主題分為幾個子主題。你需要為這些題目寫幾章內(nèi)容，也需要在這些章節(jié)中寫前言，簡介， 例子和其他段落。 ? 你需要為寫個整體框架，并學習一些很好的寫作技巧以便讀者能更容易明白你要說的內(nèi)容。這就是整體規(guī)劃。

在軟件開發(fā)中，OOD是整體思路。在某種程度上，設(shè)計軟件時，你的類和代碼需能達到模塊化，可復(fù)用，且靈活，這些很不錯的指導(dǎo)原則不用你重新發(fā)明創(chuàng)造。確實有些原則你已經(jīng)在你的類和對象中已經(jīng)用到了，對嗎？

Farhana :嗯...有個大概的印象了，但需要繼續(xù)深入。

Shubho :別擔心，你馬上就會學到。我們繼續(xù)討論下去。

為什么要OOD？

Shubho :這是一個非常重要的問題。當我們能很快地設(shè)計一些類，完成開發(fā)并發(fā)布時，為什么我們需要關(guān)心OOD？那樣子還不夠嗎？

Farhana :嗯，我早先并不知道OOD，我一直就是開發(fā)并發(fā)布項目。那么關(guān)鍵是什么？

Shubho :好的，我先給你一句名言：

走在結(jié)冰的河邊不會濕鞋，開發(fā)需求不變的項目暢通無阻(Walking on water and developing software from a specification are easy if both are frozen )

-Edward V. ?Berard

Farhana :你的意思是軟件開發(fā)說明書會不斷變化？

Shubho :非常正確！軟件開發(fā)唯一的真理是“軟件一定會變化”。為什么?

因為你的軟件解決的是現(xiàn)實生活中的業(yè)務(wù)問題，而現(xiàn)實生活中得業(yè)務(wù)流程總是在不停的變化。

假設(shè)你的軟件在今天工作的很好。但它能靈活的支持“變化”嗎？如果不能，那么你就沒有一個設(shè)計敏捷的軟件。

Farhana :好，那么請解釋一下“設(shè)計敏捷的軟件”。

Shubho :"一個設(shè)計敏捷的軟件能輕松應(yīng)對變化，能被擴展，并且能被復(fù)用。"

并且應(yīng)用好"面向?qū)ο笤O(shè)計"是做到敏捷設(shè)計的關(guān)鍵。那么，你什么時候能說你在代碼中很好的應(yīng)用了OOD？

Farhana :這正是我的問題。

Shubho :如果你代碼能做到以下幾點，那么你就正在OOD：

• 面向?qū)ο?/li>
• 復(fù)用
• 能以最小的代價滿足變化
• 不用改變現(xiàn)有代碼滿足擴展

Farhana ：還有？

Shubho :我們并不是孤立的。很多人在這個問題上思考了很多，也花費了很大努力，他們試圖做好OOD，并為OOD指出幾條基本的原則(那些靈感你能用之于你的OOD)。他們最終也確實總結(jié)出了一些通用的設(shè)計模式(基于基本的原則)。

Farhana :你能說幾個嗎？

Shubho :當然。這里有很多涉及原則，但最基本的是叫做SOLID的5原則(感謝Uncle Bob,偉大OOD導(dǎo)師)。

?

S = 單一職責原則 Single Responsibility Principle
O = 開放閉合原則 Opened Closed Principle
L = Liscov替換原則 Liscov Substitution Principle
I = 接口隔離原則 Interface Segregation Principle
D = 依賴倒置原則 Dependency Inversion Principle

?

接下去，我們會仔細探討每一個原則。

單一職責原則

Shubho :我先給你展示一張海報。我們應(yīng)當謝謝做這張海報的人，它非常有意思。

單一職責原則海報

它說："并不是因為你能，你就應(yīng)該做"。為什么？因為長遠來看它會帶來很多管理問題。

從面向?qū)ο蠼嵌冉忉尀?#xff1a;"引起類變化的因素永遠不要多于一個。 "

或者說"一個類有且只有一個職責"。

Farhana ：能解釋一下嗎？

Shubho :當然，這個原則是說，如果你的類有多于一個原因會導(dǎo)致它變化(或者多于一個職責)，你需要一句它們的職責把這個類拆分為多個類。

Farhana :嗯...這是不是意味著在一個類里不能有多個方法？

Shubho :不。你當然可以在一個類中包含多個方法。問題是，他們都是為了一個目的。如今為什么拆分是重要的？

那是因為：

• 每個職責是軸向變化的；
• 如果類包含多個職責，代碼會變得耦合；

Farhana :能給我一個例子嗎？

Shubho :當然，看一下下面的類層次。當然這個例子是從Uncle Bob那里得來，再謝謝他。

違反單一職責原則的類結(jié)構(gòu)圖

這里，Rectangle 類做了下面兩件事：

• 計算矩形面積；
• 在界面上繪制矩形；

并且，有兩個應(yīng)用使用了Rectangle 類：

• 計算幾何應(yīng)用程序用這個類計算面積；
• 圖形程序用這個類在界面上繪制矩形；

這違反了SRP(單一職責原則);

Farhana :如何違反的？

Shubho :你看，Rectangle類做了兩件事。在一個方法里它計算了面積，在另外一個方法了它返回一個表示矩形的GUI。這會帶來一些有趣的問題：

在計算幾何應(yīng)用程序中我們必須包含GUI。也就是在開發(fā)幾何應(yīng)用時，我們必須引用GUI庫；

圖形應(yīng)用中Rectangle類的變化可能導(dǎo)致計算幾何應(yīng)用變化，編譯和測試，反之亦然；

Farhana :有點意思。那么我猜我們應(yīng)該依據(jù)職責拆分這個類，對嗎？

Shubho :非常對，你猜我們應(yīng)該做些什么？

Farhana :當然，我試試。下面是我們可能要做的：

拆分職責到兩個不同的類中，如：

• Rectangle :這個類應(yīng)該定義Area() 方法；
• RectangleUI :這個類應(yīng)繼承Rectangle 類，并定義Draw() 方法。

Shubho :非常好。在這里，Rectangle 類被計算幾何應(yīng)用使用，而RectangleUI 被圖形應(yīng)用使用。我們甚至可以分離這些類到兩個獨立的DLL中，那會允許我們在變化時不需要關(guān)心另一個就可以實現(xiàn)它。

Farhana :謝謝，我想我明白SRP了。SRP看起來是把事物分離成分子部分，以便于能被復(fù)用和集中管理。我們也不能把SRP用到方法級別嗎？我的意思是，我們可以寫一些方法，它們包含做很多事的代碼。這些方法可能違反SRP，對嗎？

Shubho :你理解了。你應(yīng)當分解你的方法，讓每個方法只做某一項工作。那樣允許你復(fù)用方法，并且一旦出現(xiàn)變化，你能購以修改最少的代碼滿足變化。

開放閉合原則

Shubho :這里是開放閉合原則的海報

開放閉合原則海報

從面向?qū)ο笤O(shè)計角度看,它可以這么說:"軟件實體(類,模塊,函數(shù)等等)應(yīng)當對擴展開放，對修改閉合。 "

通俗來講，它意味著你應(yīng)當能在不修改類的前提下擴展一個類的行為。就好像我不需要改變我的身體而可以穿上衣服。

Farhana :有趣。你能夠按照你意愿穿上不同的衣服來改變面貌，而從不用改造身體。你對擴展開放了，對不？

Shubho :是的。在OOD里，對擴展開發(fā)意味著類或模塊的行為能夠改變，在需求變化時我們能以新的，不同的方式讓模塊改變，或者在新的應(yīng)用中滿足需求。

Farhana :并且你的身體對修改是閉合的。我喜歡這個例子。當需要變化時，核心類或模塊的源代碼不應(yīng)當改動。你能用些例子解釋一下嗎？

Shubho :當然，看下面這個例子。它不支持"開放閉合"原則。

違反開發(fā)閉合原則的類結(jié)構(gòu)

你看，客戶端和服務(wù)段都耦合在一起。那么，只要出現(xiàn)任何變化，服務(wù)端變化了，客戶端一樣需要改變。

Farhana :理解。如果一個瀏覽器以緊耦合的方式按照指定的服務(wù)器(比如IIS)實現(xiàn)，那么如果服務(wù)器因為某些原因被其他服務(wù)器(如Apache)替換了，那么瀏覽器也需要修改或替換。這確實很可怕！

Shubho :對的。下面是正確的設(shè)計。

遵循開放閉合原則的類結(jié)構(gòu)

在這個例子中，添加了一個抽象的服務(wù)器類，客戶端包含一個抽象類的引用，具體的服務(wù)類實現(xiàn)了抽象服務(wù)類。那么，因任何原因引起服務(wù)實現(xiàn)發(fā)生變化時，客戶端都不需要任何改變。

這里抽象服務(wù)類對修改是閉合的，實體類的實現(xiàn)對擴展是開放的。

Farhana :我明白了，抽象是關(guān)鍵，對嗎？

Shubho : 是的，基本上，你抽象的東西是你系統(tǒng)的核心內(nèi)容，如果你抽象的好，很可能在擴展功能時它不需要任何修改(就像服務(wù)是一個抽象概念)。如果在實現(xiàn)里定義了抽 象的東西(比如IIS服務(wù)器實現(xiàn)的服務(wù))，代碼要盡可能以抽象(服務(wù))為依據(jù)。這會允許你擴展抽象事物，定義一個新的實現(xiàn)(如Apache服務(wù)器)而不需 要修改任何客戶端代碼。

Liskov's 替換原則

Shubho :"Liskov's替換原則(LSP)"聽起來很難，卻是很有用的基本概念。看下這幅有趣的海報：

Liskov替換原則海報

這個原則意思是："子類型必須能夠替換它們基類型。 "

或者換個說法："使用基類引用的函數(shù)必須能使用繼承類的對象而不必知道它。 "

Farhana :不好意思，聽起來有點困惑。我認為這個OOP的基本原則之一。也就是多態(tài)，對嗎？為什么一個面向?qū)ο笤瓌t需要這么說呢？

Shubho :問的好。這就是你的答案：

在基本的面向?qū)ο笤瓌t里，"繼承"通常是"is a "的關(guān)系。如果"Developer " 是一個"SoftwareProfessional ",那么"Developer "類應(yīng)當繼承"SoftwareProfessional "類。在類設(shè)計中"Is a "關(guān)系非常重要，但它容易沖昏頭腦，結(jié)果使用錯誤的繼承造成錯誤設(shè)計。

"Liskov替換原則 "正是保證繼承能夠被正確使用的方法。

Farhana :我明白了。有意思。

Shubho :是的，親愛的，確實。我們看個例子：

Liskov替換原則類結(jié)構(gòu)圖

這里，KingFisher 類擴展了Bird 基類，并繼承了Fly() 方法，這看起來沒問題。

現(xiàn)在看下面的例子：

違反Liskov替換原則類結(jié)構(gòu)圖

Ostrich (鴕鳥)是一種鳥(顯然是),并從Bird 類繼承。它能飛嗎？不能，這個設(shè)計就違反了LSP。

所以，即使在現(xiàn)實中看起來沒問題，在類設(shè)計中，Ostrich 不應(yīng)該從Bird 類繼承，這里應(yīng)該從Bird 中分離一個不會飛的類，Ostrich 應(yīng)該繼承與它。

Farhana :好，明白了。那么讓我來試著指出為什么LSP這么重要：

• 如果沒有LSP，類繼承就會混亂；如果子類作為一個參數(shù)傳遞給方法，將會出現(xiàn)未知行為；
• 如果沒有LSP，適用與基類的單元測試將不能成功用于測試子類；

對嗎？

Shubho :非常正確。你能設(shè)計對象，使用LSP做為一個檢查工作來測試繼承是否正確。

接口分離原則

Shubho :今天我們學習"接口分離原則",這是海報：

接口分離原則海報

Farhana :這是什么意思？

Shubho :它的意思是："客戶端不應(yīng)該被迫依賴于它們不用的接口。"

Farhana :請解釋一下。

Shubho :當然，這是解釋：

假設(shè)你想買個電視機，你有兩個選擇。一個有很多開關(guān)和按鈕，它們看起來很混亂，且好像對你來說沒必要。另一個只有幾個開關(guān)和按鈕，它們很友好，且適合你使用。假定兩個電視機提供同樣的功能，你會選哪一個？

Farhana :當然是只有幾個開關(guān)和按鈕的第二個。

Shubho :對，但為什么？

Farhana :因為我不需要那些看起來混亂又對我沒用的開關(guān)和按鈕。

?

Shubho :以便外部能夠知道這些類有哪些可用的功能,客戶端代碼也能根據(jù)接口來設(shè)計.現(xiàn)在,如果接口太大,包含很多暴露的方法,在外界看來會很混亂.接口包含太多的方法也使其可用性降低,像這種包含了無用方法的"胖接口"會增加類之間的耦合. 你通過接口暴露類的功能,對.同樣地,假設(shè)你有一些類,

這也引起了其他問題.如果一個類想實現(xiàn)該接口,那么它需要實現(xiàn)所有的方法,盡管有些對它來說可能完全沒用.所以說這么做會在系統(tǒng)中引入不必要的復(fù)雜度,降低可維護性或魯棒性.

接口隔離原則確保實現(xiàn)的接口有他們共同的職責,它們是明確的,易理解的,可復(fù)用的.

Farhana : 你的意思是接口應(yīng)該僅包含必要的方法,而不該包含其它的. 我明白了.

Shubho :非常正確.一起看個例子.

下面是違反接口隔離原則的一個胖接口 ?

?

注意到IBird 接口包含很多鳥類的行為,包括Fly() 行為.現(xiàn)在如果一個Bird 類(如Ostrich)實現(xiàn)了這個接口，那么它需要實現(xiàn)不必要的Fly() 行為(Ostrich不會飛).

Farhana :確實如此。那么這個接口必須拆分了？

Shubho :是的。這個"胖接口"應(yīng)該拆分未兩個不同的接口，IBird 和IFlyingBird ,IFlyingBird 繼承自IBird .

?

?

這里如果一種鳥不會飛(如Ostrich)，那它實現(xiàn)IBird接口 。如果一種鳥會飛(如KingFisher)，那么它實現(xiàn)IFlyingBird .

Farhana :所以回頭看包含了很多開關(guān)和按鈕的電視機的例子，電視機制造商應(yīng)該有一個電視機的圖紙，開關(guān)和按鈕都在這個方案里。不論任何時候，當他們向制造一種新款電視機時，如果他們想復(fù)用這個圖紙，他們將需要在這個方案里添加更多的開關(guān)和按鈕。那么他們將沒法復(fù)用這個方案，對嗎？

Shubho :對的。

Farhana :如果他們確實需要復(fù)用方案，它們應(yīng)當把電視機的圖紙份為更小部分，以便在任何需要造新款電視機的時候復(fù)用這點小部分。

Shubho :你理解了。

依賴倒置原則

Shubho :這是SOLID原則里最后一個原則。這是海報

? ?

它的意思是：高層模塊不應(yīng)該依賴底層模塊，兩者都應(yīng)該依賴其抽象

Shubho :考慮一個現(xiàn)實中的例子。你的汽車是由很多如引擎，車輪，空調(diào)和其它等部件組成，對嗎？

Farhana :是的

Shubho :好，它們沒有一個是嚴格的構(gòu)建在一個單一單元里；換句話說，它們都是可插拔的，因此當引擎或車輪出問題時，你可以修理它(而不需要修理其它部件),甚至可以換一個。

在替換時，你僅需要確保引擎或車輪符合汽車的設(shè)計(如汽車能使用任何1500CC的引擎或任何18寸的車輪)。

當然，汽車也可能允許你在1500CC引擎的地方安裝一個2000CC的引擎，事實上對某些制造商(如豐田汽車)是一樣的。

現(xiàn)在，如果你的汽車的零部件不具備可插拔性會有什么不同？

Farhana :那會很可怕！因為如果汽車的引擎出故障了，你可能修理整部車或者需要買一個新的。

Shubho :是的，那么該如何做到"可插拔性"呢？

Farhana :這里抽象是關(guān)鍵，對嗎？

Shubho :是的，在現(xiàn)實中，汽車是高級模塊或?qū)嶓w，它依賴于低級模塊或?qū)嶓w，如引擎或車輪。

相比直接依賴于引擎或車輪，汽車應(yīng)依賴于某些抽象的有規(guī)格的引擎或車輪，以便于如果任何引擎或車輪符合抽象，那么它們都能組合到汽車中，汽車也能跑動。

一起看下面的類圖

? ?

Shubho :注意到上面Car 類有兩個屬性，它們都是抽象類型(接口)。引擎和車輪是可插拔的，因為汽車能接受任何實現(xiàn)了聲明接口的對象，并且Car 類不需要做任何改動。

Farhana :所以，如果代碼中不用依賴倒置，我們將面臨如下風險：

• 使用低級類會破環(huán)高級代碼；

• 當?shù)图夘愖兓瘯r需要很多時間和代價來修改高級代碼；

• 產(chǎn)生低復(fù)用的代碼；

Shubho :你完全掌握了，親愛的！

? 總結(jié)

Shubho ：除SOLID原則外還有很多其它的面向?qū)ο笤瓌t。如：

"組合替代繼承":這是說相對于繼承，要更傾向于使用組合；

"笛米特法則"：這是說"你的類對其它類知道的越少越好"；

"共同封閉原則"：這是說"相關(guān)類應(yīng)該打包在一起"；

"穩(wěn)定抽象原則"：這是說"類越穩(wěn)定，越應(yīng)該由抽象類組成";

Farhana :我應(yīng)該學習那些原則嗎？

Shubho :當然可以。你可以從整個網(wǎng)上學習。僅僅需要Google一下那些原則，然后嘗試理解它。當然如果有需要，盡管問我。

Farhana :在那些設(shè)計原則之上我聽說過很多設(shè)計模式。

Shubho :對的。設(shè)計模式只是對一些經(jīng)常出現(xiàn)的場景的一些通用設(shè)計建議。這些靈感主要來自于面向?qū)ο笤瓌t。你可以把設(shè)計模式看作"框架",把OOD原則看作"規(guī)范".

Farhana :那么接下去我將學習設(shè)計模式嗎？

Shubho :是的，親愛的。

Farhana :那會很有意思，對嗎？

Shubho :是，那確實令人興奮。

-------------------------------------------------------------------------------------------------------------------

聲明:

本文版權(quán)歸作者共有，歡迎轉(zhuǎn)載，但未經(jīng)作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文出處，連接，作者，否則保留追究法律責任的權(quán)利。

http://archive.cnblogs.com/a/1940603/ ?譯文原文

http://www.codeproject.com/KB/architecture/SOLIDPrinciplesInOOD.aspx ?原文

轉(zhuǎn)載于:https://my.oschina.net/dake/blog/196710

總結(jié)

以上是生活随笔為你收集整理的如何向妻子解释OOD的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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