国产探花免费观看_亚洲丰满少妇自慰呻吟_97日韩有码在线_资源在线日韩欧美_一区二区精品毛片,辰东完美世界有声小说,欢乐颂第一季,yy玄幻小说排行榜完本

首頁 > 學院 > 開發(fā)設(shè)計 > 正文

設(shè)計模式——設(shè)計原則

2019-11-10 21:15:50
字體:
供稿:網(wǎng)友

面向?qū)ο笤瓌t、OOD和OOP概述

面向?qū)ο笤瓌t和OOD實際上是兩個不同的方面。

 面向?qū)ο笤瓌t:封裝、繼承、多態(tài)。

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

現(xiàn)在假定你需要就某些主題寫幾篇文章或隨筆。你也希望就幾個你擅長主題寫幾本書。對寫好文章/隨筆或書來說,知道如何造句是不夠的。為了使讀者能更輕松的明白你講的內(nèi)容,你需要寫更多的內(nèi)容,學習以更好的方式解釋它。如果你想就某個主題寫一本書,如學習OOD,你知道如何把一個主題分為幾個子主題。你需要為這些題目寫幾章內(nèi)容,也需要在這些章節(jié)中寫前言,簡介,例子和其他段落。 你需要為寫個整體框架,并學習一些很好的寫作技巧以便讀者能更容易明白你要說的內(nèi)容。這就是整體規(guī)劃。

 

在軟件開發(fā)中,OOD是整體思路。在某種程度上,設(shè)計軟件時,你的類和代碼需能達到模塊化,可復用,且靈活,這些很不錯的指導原則不用你重新發(fā)明創(chuàng)造。而且有些原則你在自己的代碼中可能用到了。

為什么要OOD? 

軟件開發(fā)唯一的真理是“軟件一定會變化”。為什么?因為你的軟件解決的是現(xiàn)實生活中的業(yè)務(wù)問題,而現(xiàn)實生活中的業(yè)務(wù)流程總是在不停的變化。

假設(shè)你的軟件在今天工作的很好。但它能靈活的支持“變化”嗎?如果不能,那么你就沒有一個設(shè)計敏捷的軟件(一個設(shè)計敏捷的軟件能輕松應對變化,能被擴展,并且能被復用)。并且應用好OOD是做到敏捷設(shè)計的關(guān)鍵。

 

做到OOD的代碼需要滿足的條件:

1、面向?qū)ο?/p>

2、復用

3、能以最小的代價滿足變化

4、不用改變現(xiàn)有代碼滿足擴展

OOD最基本的原則

最基本的是叫做SOLID的5原則(感謝Uncle Bob,偉大OOD導師)。

S = 單一職責原則 Single Responsibility PRinciple

O = 開放閉合原則 Opened Closed Principle

L = Liscov替換原則 Liscov Substitution Principle

I = 接口隔離原則 Interface Segregation Principle

D = 依賴倒置原則 Dependency Inversion Principle

單一職責原則 Single Responsibility Principle

單一職責原則海報

海報上說:"并不是因為你能,你就應該做"。為什么?因為長遠來看它會帶來很多管理問題。

 

從面向?qū)ο蠼嵌冉忉尀椋?quot;引起類變化的因素永遠不要多于一個。"或者說"一個類有且只有一個職責"。這個原則是說,如果你的類有多于一個原因會導致它變化(或者多于一個職責),你需要依據(jù)它們的職責把這個類拆分為多個類。

當然可以在一個類中包含多個方法。問題是,他們都是為了一個目的。如今為什么拆分很重要?

 

那是因為:

 1、每個職責是軸向變化的;

 2、如果類包含多個職責,代碼會變得耦合;

 

看一下下面的類層次。

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

 

這里,Rectangle類做了下面兩件事:

 1、計算矩形面積;

 2、在界面上繪制矩形;

 

并且,有兩個應用使用了Rectangle類:

 1、計算幾何應用程序用這個類計算面積;

 2、圖形程序用這個類在界面上繪制矩形;

 

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

1.在計算幾何應用程序中我們必須包含GUI。也就是在開發(fā)幾何應用時,我們必須引用GUI庫;

2.圖形應用中Rectangle類的變化可能導致計算幾何應用變化,編譯和測試,反之亦然;

 

應該依據(jù)職責拆分這個類,拆分職責到兩個不同的類中,如:

Rectangle:這個類應該定義Area()方法;

RectangleUI:這個類應繼承Rectangle類,并定義Draw()方法。

 

   SRP是把事物分離成分子部分,以便于能被復用和集中管理。我們也可以把SRP應用到方法之中,應當分解你的方法,讓每個方法只做某一項工作。那樣允許你復用方法,并且一旦出現(xiàn)變化,你能購以修改最少的代碼滿足變化。

開放閉合原則 Opened Closed Principle

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

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

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

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

 

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

 

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

Liscov替換原則 Liscov Substitution Principle

這個原則意思是:"子類型必須能夠替換它們父類型。"或者換個說法:"使用父類引用的函數(shù)必須能使用子類的對象而不必知道它。"

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

 

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

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

 

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

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

 

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

 

為什么LSP這么重要:

如果沒有LSP,類繼承就會混亂;如果子類作為一個參數(shù)傳遞給方法,將會出現(xiàn)未知行為;

如果沒有LSP,適用與基類的單元測試將不能成功用于測試子類;

接口隔離原則 Interface Segregation Principle

它的意思是:"客戶端不應該被迫依賴于它們不用的接口。"

假設(shè)你想買個電視機,你有兩個選擇。一個有很多開關(guān)和按鈕,它們看起來很混亂,且好像對你來說沒必要。另一個只有幾個開關(guān)和按鈕,它們很友好,且適合你使用。假定兩個電視機提供同樣的功能,你會選哪一個?答:第二個,因為我不需要那些看起來混亂又對我沒用的開關(guān)和按鈕。

以便外部能夠知道這些類有哪些可用的功能,客戶端代碼也能根據(jù)接口來設(shè)計.現(xiàn)在,如果接口太大,包含很多暴露的方法,在外界看來會很混亂.接口包含太多的方法也使其可用性降低,像這種包含了無用方法的"胖接口"會增加類之間的耦合.你通過接口暴露類的功能,同樣地,假設(shè)你有一些類,如果一個類想實現(xiàn)該接口,那么它需要實現(xiàn)所有的方法,盡管有些對它來說可能完全沒用.所以說這么做會在系統(tǒng)中引入不必要的復雜度,降低可維護性或魯棒性.

 

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

 

接口應該僅包含必要的方法,而不該包含其它的。

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

所以,這個"胖接口"應該拆分未兩個不同的接口,IBird和IFlyingBird,IFlyingBird繼承自IBird.

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

 

    所以回頭看包含了很多開關(guān)和按鈕的電視機的例子,電視機制造商應該有一個電視機的圖紙,開關(guān)和按鈕都在這個方案里。不論任何時候,當他們向制造一種新款電視機時,如果他們想復用這個圖紙,他們將需要在這個方案里添加更多的開關(guān)和按鈕。那么他們將沒法復用這個方案。如果他們確實需要復用方案,它們應當把電視機的圖紙份為更小部分,以便在任何需要造新款電視機的時候復用這點小部分。

依賴倒置原則 Dependency Inversion Principle

它的意思是:高層模塊不應該依賴底層模塊,兩者都應該依賴其抽象。

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

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

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

 

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

如果你的汽車的零部件不具備可插拔性會有什么不同?那會很可怕!因為如果汽車的引擎出故障了,你可能修理整部車或者需要買一個新的。

 

如何做到"可插拔性"呢?關(guān)鍵就是抽象。

在現(xiàn)實中,汽車是高級模塊或?qū)嶓w,它依賴于低級模塊或?qū)嶓w,如引擎或車輪。相比直接依賴于引擎或車輪,汽車應依賴于某些抽象的有規(guī)格的引擎或車輪,以便于如果任何引擎或車輪符合抽象,那么它們都能組合到汽車中,汽車也能跑動。

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

 

如果代碼中不用依賴倒置,我們將面臨如下風險:

1、使用低級類會破環(huán)高級代碼;

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

3、產(chǎn)生低復用的代碼;

其他面向?qū)ο笤瓌t

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

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

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

"共同封閉原則":這是說"相關(guān)類應該打包在一起";

"穩(wěn)定抽象原則":這是說"類越穩(wěn)定,越應該由抽象類組成";

 

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


發(fā)表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發(fā)表
主站蜘蛛池模板: 通许县| 馆陶县| 平远县| 营口市| 来凤县| 溧阳市| 广安市| 罗江县| 象州县| 得荣县| 宜兰县| 景东| 香港| 桐城市| 内乡县| 故城县| 商南县| 衡南县| 诸城市| 抚顺市| 柯坪县| 田阳县| 阳信县| 汶川县| 桂阳县| 深水埗区| 晋城| 西和县| 盱眙县| 嘉义市| 城固县| 靖边县| 赫章县| 潍坊市| 循化| 万安县| 云林县| 闻喜县| 永丰县| 蒲江县| 梓潼县|