C#面向?qū)ο笤O(shè)計(jì)的七大原則
本文我們要談的七大原則,即:單一職責(zé),里氏替換,迪米特法則,依賴倒轉(zhuǎn),接口隔離,合成/聚合原則,開(kāi)放-封閉 。
1. 開(kāi)閉原則(Open-Closed Principle, OCP)
定義:軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放,對(duì)修改關(guān)閉。這句話說(shuō)得有點(diǎn)專業(yè),更通俗一點(diǎn)講,也就是:軟件系統(tǒng)中包含的各種組件,例如模塊(Modules)、類(Classes)以及功能(Functions)等等,應(yīng)該在不修改現(xiàn)有代碼的基礎(chǔ)上,去擴(kuò)展新功能。開(kāi)閉原則中原有“開(kāi)”,是指對(duì)于組件功能的擴(kuò)展是開(kāi)放的,是允許對(duì)其進(jìn)行功能擴(kuò)展的;開(kāi)閉原則中“閉”,是指對(duì)于代碼的修改是封閉的,即不應(yīng)該修改原有的代碼。
問(wèn)題由來(lái):凡事的產(chǎn)生都有緣由。我們來(lái)看看,開(kāi)閉原則的產(chǎn)生緣由。在軟件的生命周期內(nèi),因?yàn)樽兓?、升?jí)和維護(hù)等原因需要對(duì)軟件原有代碼進(jìn)行修改時(shí),可能會(huì)給舊代碼中引入錯(cuò)誤,也可能會(huì)使我們不得不對(duì)整個(gè)功能進(jìn)行重構(gòu),并且需要原有代碼經(jīng)過(guò)重新測(cè)試。這就對(duì)我們的整個(gè)系統(tǒng)的影響特別大,這也充分展現(xiàn)出了系統(tǒng)的耦合性如果太高,會(huì)大大的增加后期的擴(kuò)展,維護(hù)。為了解決這個(gè)問(wèn)題,故人們總結(jié)出了開(kāi)閉原則。解決開(kāi)閉原則的根本其實(shí)還是在解耦合。所以,我們面向?qū)ο蟮拈_(kāi)發(fā),我們最根本的任務(wù)就是解耦合。
解決方法:當(dāng)軟件需要變化時(shí),盡量通過(guò)擴(kuò)展軟件實(shí)體的行為來(lái)實(shí)現(xiàn)變化,而不是通過(guò)修改已有的代碼來(lái)實(shí)現(xiàn)變化。
小結(jié):開(kāi)閉原則具有理想主義的色彩,說(shuō)的很抽象,它是面向?qū)ο笤O(shè)計(jì)的終極目標(biāo)。其他幾條原則,則可以看做是開(kāi)閉原則的實(shí)現(xiàn)。我們要用抽象構(gòu)建框架,用實(shí)現(xiàn)擴(kuò)展細(xì)節(jié)。
2. 單一職責(zé)原則(Single Responsibility Principle)
定義:一個(gè)類,只有一個(gè)引起它變化的原因。即:應(yīng)該只有一個(gè)職責(zé)。
每一個(gè)職責(zé)都是變化的一個(gè)軸線,如果一個(gè)類有一個(gè)以上的職責(zé),這些職責(zé)就耦合在了一起。這會(huì)導(dǎo)致脆弱的設(shè)計(jì)。當(dāng)一個(gè)職責(zé)發(fā)生變化時(shí),可能會(huì)影響其它的職責(zé)。另外,多個(gè)職責(zé)耦合在一起,會(huì)影響復(fù)用性。例如:要實(shí)現(xiàn)邏輯和界面的分離。需要說(shuō)明的一點(diǎn)是單一職責(zé)原則不只是面向?qū)ο缶幊趟枷胨赜械?,只要是模塊化的程序設(shè)計(jì),都需要遵循這一重要原則。
問(wèn)題由來(lái):類T負(fù)責(zé)兩個(gè)不同的職責(zé):職責(zé)P1,職責(zé)P2。當(dāng)由于職責(zé)P1需求發(fā)生改變而需要修改類T時(shí),有可能會(huì)導(dǎo)致原本運(yùn)行正常的職責(zé)P2功能發(fā)生故障。
解決方法:分別建立兩個(gè)類T1、T2,使T1完成職責(zé)P1功能,T2完成職責(zé)P2功能。這樣,當(dāng)修改類T1時(shí),不會(huì)使職責(zé)P2發(fā)生故障風(fēng)險(xiǎn);同理,當(dāng)修改T2時(shí),也不會(huì)使職責(zé)P1發(fā)生故障風(fēng)險(xiǎn)。
3. 里氏替換原則(Liskov Substitution Principle)
定義:子類型必須能夠替換掉它們的父類型。注意這里的能夠兩字。有人也戲稱老鼠的兒子會(huì)打洞原則。
問(wèn)題由來(lái):有一功能P1,由類A完成。現(xiàn)需要將功能P1進(jìn)行擴(kuò)展,擴(kuò)展后的功能為P,其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來(lái)完成,則子類B在完成新功能P2的同時(shí),有可能會(huì)導(dǎo)致原有功能P1發(fā)生故障。
解決方法:類B繼承類A時(shí),除添加新的方法完成新增功能P2外,盡量不要重寫父類A的方法,也盡量不要重載父類A的方法
小結(jié):所有引用父類的地方必須能透明地使用其子類的對(duì)象。子類可以擴(kuò)展父類的功能,但不能改變父類原有的功能,即:子類可以實(shí)現(xiàn)父類的抽象方法,子類也中可以增加自己特有的方法,但不能覆蓋父類的非抽象方法。當(dāng)子類的方法重載父類的方法時(shí),方法的前置條件(即方法的形參)要比父類方法的輸入?yún)?shù)更寬松。當(dāng)子類的方法實(shí)現(xiàn)父類的抽象方法時(shí),方法的后置條件(即方法的返回值)要比父類更嚴(yán)格。
4. 迪米特法則(Law Of Demeter)
定義:迪米特法則又叫最少知道原則,即:一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象保持最少的了解。如果兩個(gè)類不必彼此直接通信,那么這兩個(gè)類就不應(yīng)當(dāng)發(fā)生直接的相互作用。如果其中一個(gè)類需要調(diào)用另一個(gè)類的某一個(gè)方法的話,可以通過(guò)第三者轉(zhuǎn)發(fā)這個(gè)調(diào)用。簡(jiǎn)單定義為只與直接的朋友通信。首先來(lái)解釋一下什么是直接的朋友:每個(gè)對(duì)象都會(huì)與其他對(duì)象有耦合關(guān)系,只要兩個(gè)對(duì)象之間有耦合關(guān)系,我們就說(shuō)這兩個(gè)對(duì)象之間是朋友關(guān)系。耦合的方式很多,依賴、關(guān)聯(lián)、組合、聚合等。其中,我們稱出現(xiàn)成員變量、方法參數(shù)、方法返回值中的類為直接的朋友,而出現(xiàn)在局部變量中的類則不是直接的朋友。也就是說(shuō),陌生的類最好不要作為局部變量的形式出現(xiàn)在類的內(nèi)部。
問(wèn)題由來(lái):類與類之間的關(guān)系越密切,耦合度越大,當(dāng)一個(gè)類發(fā)生改變時(shí),對(duì)另一個(gè)類的影響也越大。
最早是在1987年由美國(guó)Northeastern University的Ian Holland提出。通俗的來(lái)講,就是一個(gè)類對(duì)自己依賴的類知道的越少越好。也就是說(shuō),對(duì)于被依賴的類來(lái)說(shuō),無(wú)論邏輯多么復(fù)雜,都盡量地的將邏輯封裝在類的內(nèi)部,對(duì)外除了提供的public方法,不對(duì)外泄漏任何信息。迪米特法則還有一個(gè)更簡(jiǎn)單的定義:只與直接的朋友通信。
解決方法:盡量降低類與類之間的耦合。 自從我們接觸編程開(kāi)始,就知道了軟件編程的總的原則:低耦合,高內(nèi)聚。無(wú)論是面向過(guò)程編程還是面向?qū)ο缶幊?,只有使各個(gè)模塊之間的耦合盡量的低,才能提高代碼的復(fù)用率。
迪米特法則的初衷是降低類之間的耦合,由于每個(gè)類都減少了不必要的依賴,因此的確可以降低耦合關(guān)系。但是凡事都有度,雖然可以避免與非直接的類通信,但是要通信,必然會(huì)通過(guò)一個(gè)“中介”來(lái)發(fā)生聯(lián)系。故過(guò)分的使用迪米特原則,會(huì)產(chǎn)生大量這樣的中介和傳遞類,導(dǎo)致系統(tǒng)復(fù)雜度變大。所以在采用迪米特法則時(shí)要反復(fù)權(quán)衡,既做到結(jié)構(gòu)清晰,又要高內(nèi)聚低耦合。
5. 依賴倒置原則(Dependence Inversion Principle)
定義:高層模塊不應(yīng)該依賴低層模塊,二者都應(yīng)該依賴其抽象;抽象不應(yīng)該依賴細(xì)節(jié);細(xì)節(jié)應(yīng)該依賴抽象。中心思想是面向接口編程
問(wèn)題由來(lái):類A直接依賴類B,假如要將類A改為依賴類C,則必須通過(guò)修改類A的代碼來(lái)達(dá)成。這種場(chǎng)景下,類A一般是高層模塊,負(fù)責(zé)復(fù)雜的業(yè)務(wù)邏輯;類B和類C是低層模塊,負(fù)責(zé)基本的原子操作;假如修改類A,會(huì)給程序帶來(lái)不必要的風(fēng)險(xiǎn)。
解決方法:將類A修改為依賴接口I,類B和類C各自實(shí)現(xiàn)接口I,類A通過(guò)接口I間接與類B或者類C發(fā)生聯(lián)系,則會(huì)大大降低修改類A的幾率。
在實(shí)際編程中,我們一般需要做到如下3點(diǎn):
1). 低層模塊盡量都要有抽象類或接口,或者兩者都有。
2). 變量的聲明類型盡量是抽象類或接口。
3). 使用繼承時(shí)遵循里氏替換原則。
采用依賴倒置原則尤其給多人合作開(kāi)發(fā)帶來(lái)了極大的便利,參與協(xié)作開(kāi)發(fā)的人越多、項(xiàng)目越龐大,采用依賴導(dǎo)致原則的意義就越重大。
小結(jié):依賴倒置原則就是要我們面向接口編程,理解了面向接口編程,也就理解了依賴倒置。
6. 接口隔離原則(Interface Segregation Principle)
定義:客戶端不應(yīng)該依賴它不需要的接口;一個(gè)類對(duì)另一個(gè)類的依賴應(yīng)該建立在最小的接口上。
問(wèn)題由來(lái):類A通過(guò)接口I依賴類B,類C通過(guò)接口I依賴類D,如果接口I對(duì)于類A和類B來(lái)說(shuō)不是最小接口,則類B和類D必須去實(shí)現(xiàn)他們不需要的方法
解決方法:1、 使用委托分離接口。2、 使用多重繼承分離接口。3.將臃腫的接口I拆分為獨(dú)立的幾個(gè)接口,類A和類C分別與他們需要的接口建立依賴關(guān)系。也就是采用接口隔離原則。
舉例說(shuō)明:
下面我們來(lái)看張圖,一切就一目了然了。
這個(gè)圖的意思是:類A依賴接口I中的方法1、方法2、方法3,類B是對(duì)類A依賴的實(shí)現(xiàn)。類C依賴接口I中的方法1、方法4、方法5,類D是對(duì)類C依賴的實(shí)現(xiàn)。對(duì)于類B和類D來(lái)說(shuō),雖然他們都存在著用不到的方法(也就是圖中紅色字體標(biāo)記的方法),但由于實(shí)現(xiàn)了接口I,所以也必須要實(shí)現(xiàn)這些用不到的方法
修改后:
如果接口過(guò)于臃腫,只要接口中出現(xiàn)的方法,不管對(duì)依賴于它的類有沒(méi)有用處,實(shí)現(xiàn)類中都必須去實(shí)現(xiàn)這些方法,這顯然不是好的設(shè)計(jì)。如果將這個(gè)設(shè)計(jì)修改為符合接口隔離原則,就必須對(duì)接口I進(jìn)行拆分。在這里我們將原有的接口I拆分為三個(gè)接口
小結(jié):我們?cè)诖a編寫過(guò)程中,運(yùn)用接口隔離原則,一定要適度,接口設(shè)計(jì)的過(guò)大或過(guò)小都不好。對(duì)接口進(jìn)行細(xì)化可以提高程序設(shè)計(jì)靈活性是不掙的事實(shí),但是如果過(guò)小,則會(huì)造成接口數(shù)量過(guò)多,使設(shè)計(jì)復(fù)雜化。所以一定要適度。設(shè)計(jì)接口的時(shí)候,只有多花些時(shí)間去思考和籌劃,就能準(zhǔn)確地實(shí)踐這一原則。
7. 合成/聚合原則(Composite/Aggregate Reuse Principle,CARP)
定義:也有人叫做合成復(fù)用原則,及盡量使用合成/聚合,盡量不要使用類繼承。換句話說(shuō),就是能用合成/聚合的地方,絕不用繼承。
為什么要盡量使用合成/聚合而不使用類繼承?
1. 對(duì)象的繼承關(guān)系在編譯時(shí)就定義好了,所以無(wú)法在運(yùn)行時(shí)改變從父類繼承的子類的實(shí)現(xiàn)
2. 子類的實(shí)現(xiàn)和它的父類有非常緊密的依賴關(guān)系,以至于父類實(shí)現(xiàn)中的任何變化必然會(huì)導(dǎo)致子類發(fā)生變化
3. 當(dāng)你復(fù)用子類的時(shí)候,如果繼承下來(lái)的實(shí)現(xiàn)不適合解決新的問(wèn)題,則父類必須重寫或者被其它更適合的類所替換,這種依賴關(guān)系限制了靈活性,并最終限制了復(fù)用性。
總結(jié):這些原則在設(shè)計(jì)模式中體現(xiàn)的淋淋盡致,設(shè)計(jì)模式就是實(shí)現(xiàn)了這些原則,從而達(dá)到了代碼復(fù)用、增強(qiáng)了系統(tǒng)的擴(kuò)展性。所以設(shè)計(jì)模式被很多人奉為經(jīng)典。我們可以通過(guò)好好的研究設(shè)計(jì)模式,來(lái)慢慢的體會(huì)這些設(shè)計(jì)原則。
相關(guān)文章
ItemsControl 數(shù)據(jù)綁定的兩種方式
這篇文章主要介紹了ItemsControl 數(shù)據(jù)綁定的兩種方式,幫助大家更好的理解和學(xué)習(xí)使用c#,感興趣的朋友可以了解下2021-03-03C#基于Mongo的官方驅(qū)動(dòng)手?jǐn)]一個(gè)Super簡(jiǎn)易版MongoDB-ORM框架
本文給大家分享C#基于Mongo的官方驅(qū)動(dòng)手?jǐn)]一個(gè)簡(jiǎn)易版MongoDB-ORM框架,是一款屬于super簡(jiǎn)易版的,通過(guò)圖文的形式給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友參考下吧2021-05-05C#實(shí)現(xiàn)對(duì)文件進(jìn)行加密保護(hù)的示例代碼
這篇文章主要為大家詳細(xì)介紹了如何利用C#實(shí)現(xiàn)對(duì)文件進(jìn)行加密保護(hù)的功能,文中的示例代碼講解詳細(xì),對(duì)我們學(xué)習(xí)C#有一定的幫助,感興趣的小伙伴可以跟隨小編一起了解一下2022-12-12C#實(shí)現(xiàn)掃描局域網(wǎng)內(nèi)的所有IP和端口
這篇文章主要為大家詳細(xì)介紹了如何利用C#實(shí)現(xiàn)掃描局域網(wǎng)內(nèi)的所有IP和端口的功能,文中的示例代碼講解詳細(xì),對(duì)我們學(xué)習(xí)C#有一定的幫助,感興趣的小伙伴可以跟隨小編一起了解一下2022-12-12