出處:https://www.cnblogs.com/pengdai
一、開發(fā)原則
S:單一職責(zé)SRP
O:開放封閉原則OCP
L:里氏替換原則LSP
I:接口隔離法則
D:依賴倒置原則DIP
合成/聚合復(fù)用原則
迪米特法則
在軟件開發(fā)中,前人對軟件系統(tǒng)的設(shè)計和開發(fā)總結(jié)了一些原則和模式, 不管用什么語言做開發(fā),都將對我們系統(tǒng)設(shè)計和開發(fā)提供指導(dǎo)意義。本文主要將總結(jié)這些常見的原則和具體闡述意義。
面向?qū)ο蟮幕驹瓌t(solid)是五個,但是在經(jīng)常被提到的除了這五個之外還有迪米特法則和合成復(fù)用原則等,所以在常見的文章中有表示寫六大或七大原則的; 除此之外我還將給出一些其它相關(guān)書籍和互聯(lián)網(wǎng)上出現(xiàn)的原則;
二、S單一職責(zé)SRP
Single-Responsibility Principle,一個類,最好只做一件事,只有一個引起它的變化。單一職責(zé)原則可以看做是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t的引申,將職責(zé)定義為引起變化的原因,以提高內(nèi)聚性減少引起變化的原因。
1、定義
一個對象應(yīng)該只包含單一的職責(zé),并且該職責(zé)被完整地封裝在一個類中。(Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.),即又定義有且僅有一個原因使類變更。
2、原則分析
一個類或者大到模塊,小到方法,承擔(dān)的職責(zé)越多,它被復(fù)用的可能性越小,而且如果一個類承擔(dān)的職責(zé)過多,就相當(dāng)于將這些職責(zé)耦合在一起,當(dāng)其中一個職責(zé)變化時,可能會影響其他職責(zé)的運作。
類的職責(zé)主要包括兩個方面:數(shù)據(jù)職責(zé)和行為職責(zé),數(shù)據(jù)職責(zé)通過其屬性來體現(xiàn),而行為職責(zé)通過其方法來體現(xiàn)。
單一職責(zé)原則是實現(xiàn)高內(nèi)聚、低耦合的指導(dǎo)方針,在很多代碼重構(gòu)手法中都能找到它的存在,它是最簡單但又最難運用的原則,需要設(shè)計人員發(fā)現(xiàn)類的不同職責(zé)并將其分離,而發(fā)現(xiàn)類的多重職責(zé)需要設(shè)計人員具有較強的分析設(shè)計能力和相關(guān)重構(gòu)經(jīng)驗。
3、優(yōu)點
降低類的復(fù)雜性,類的職責(zé)清晰明確。比如數(shù)據(jù)職責(zé)和行為職責(zé)清晰明確;
提高類的可讀性和維護性;
變更引起的風(fēng)險減低,變更是必不可少的,如果接口的單一職責(zé)做得好,一個接口修改只對相應(yīng)的類有影響,對其他接口無影響,這對系統(tǒng)的擴展性、維護性都有非常大的幫助。
注意:單一職責(zé)原則提出了一個編寫程序的標準,用“職責(zé)”或“變化原因”來衡量接口或類設(shè)計得是否合理,但是“職責(zé)”和“變化原因”都是沒有具體標準的,一個類到底要負責(zé)那些職責(zé)?這些職責(zé)怎么細化?細化后是否都要有一個接口或類?這些都需從實際的情況考慮。因項目而異,因環(huán)境而異。
4、例子
SpringMVC中Entity、DAO、Service、Controller、Util等的分離。
三、O開放封閉原則OCP
Open - ClosedPrinciple,OCP對擴展開放,對修改關(guān)閉(設(shè)計模式的核心原則)
1、定義
一個軟件實體(如類、模塊和函數(shù))應(yīng)該對擴展開放,對修改關(guān)閉。意思是在一個系統(tǒng)或者模塊中,對于擴展是開放的,對于修改是關(guān)閉的。一個 好的系統(tǒng)是在不修改源代碼的情況下,可以擴展你的功能。而實現(xiàn)開閉原則的關(guān)鍵就是抽象化。
2、原則分析
當(dāng)軟件實體因需求要變化時, 盡量通過擴展已有軟件實體,可以提供新的行為,以滿足對軟件的新的需求,而不是修改已有的代碼,使變化中的軟件有一定的適應(yīng)性和靈活性 。已有軟件模塊,特別是最重要的抽象層模塊不能再修改,這使變化中的軟件系統(tǒng)有一定的穩(wěn)定性和延續(xù)性。
實現(xiàn)開閉原則的關(guān)鍵就是抽象化 :在"開-閉"原則中,不允許修改的是抽象的類或者接口,允許擴展的是具體的實現(xiàn)類,抽象類和接口在"開-閉"原則中扮演著極其重要的角色..即要預(yù)知可能變化的需求.又預(yù)見所有可能已知的擴展..所以在這里"抽象化"是關(guān)鍵!
可變性的封閉原則:找到系統(tǒng)的可變因素,將它封裝起來。這是對"開-閉"原則最好的實現(xiàn)。不要把你的可變因素放在多個類中,或者散落在程序的各個角落。你應(yīng)該將可變的因素,封套起來..并且切忌不要把所用的可變因素封套在一起。最好的解決辦法是,分塊封套你的可變因素!避免超大類、超長類、超長方法的出現(xiàn)!!給你的程序增加藝術(shù)氣息,將程序藝術(shù)化是我們的目標!
3、例子
設(shè)計模式中模板方法模式和觀察者模式都是開閉原則的極好體現(xiàn)。
四、L里氏替換原則LSP
Liskov Substitution Principle,LSP:任何基類可以出現(xiàn)的地方,子類也可以出現(xiàn);這一思想表現(xiàn)為對繼承機制的約束規(guī)范,只有子類能夠替換其基類時,才能夠保證系統(tǒng)在運行期內(nèi)識別子類,這是保證繼承復(fù)用的基礎(chǔ)。
1、定義
第一種定義方式相對嚴格:如果對每一個類型為S的對象o1,都有類型為T的對象o2,使得以T定義的所有程序P在所有的對象o1都代換成o2時,程序P的行為沒有變化,那么類型S是類型T的子類型。
第二種更容易理解的定義方式:所有引用基類(父類)的地方必須能透明地使用其子類的對象。即子類能夠必須能夠替換基類能夠從出現(xiàn)的地方。子類也能在基類 的基礎(chǔ)上新增行為。
里氏代換原則由2008年圖靈獎得主、美國第一位計算機科學(xué)女博士、麻省理工學(xué)院教授BarbaraLiskov和卡內(nèi)基.梅隆大學(xué)Jeannette Wing教授于1994年提出。其原文如下:Let q(x) be a property provableabout objects x of type T. Then q(y) should be true for objects y of type Swhere S is a subtype of T.
2、原則分析
講的是基類和子類的關(guān)系,只有這種關(guān)系存在時,里氏代換原則才存在。正方形是長方形是理解里氏代換原則的經(jīng)典例子。
里氏代換原則可以通俗表述為:在軟件中如果能夠使用基類對象,那么一定能夠使用其子類對象。把基類都替換成它的子類,程序?qū)⒉粫a(chǎn)生任何錯誤和異常,反過來則不成立,如果一個軟件實體使用的是一個子類的話,那么它不一定能夠使用基類。
里氏代換原則是實現(xiàn)開閉原則的重要方式之一,由于使用基類對象的地方都可以使用子類對象,因此在程序中盡量使用基類類型來對對象進行定義,而在運行時再確定其子類類型,用子類對象來替換父類對象。
五、I接口隔離法則
(Interface Segregation Principle,ISL):客戶端不應(yīng)該依賴那些它不需要的接口。(這個法則與迪米特法則是相通的)
1、定義
客戶端不應(yīng)該依賴那些它不需要的接口。
另一種定義方法:一旦一個接口太大,則需要將它分割成一些更細小的接口,使用該接口的客戶端僅需知道與之相關(guān)的方法即可。
注意,在該定義中的接口指的是所定義的方法。例如外面調(diào)用某個類的public方法。這個方法對外就是接口。
2、原則分析:
(1)接口隔離原則是指使用多個專門的接口,而不使用單一的總接口。每一個接口應(yīng)該承擔(dān)一種相對獨立的角色,不多不少,不干不該干的事,該干的事都要干。
? 一個接口就只代表一個角色,每個角色都有它特定的一個接口,此時這個原則可以叫做“角色隔離原則”。
? 接口僅僅提供客戶端需要的行為,即所需的方法,客戶端不需要的行為則隱藏起來,應(yīng)當(dāng)為客戶端提供盡可能小的單獨的接口,而不要提供大的總接口。
(2)使用接口隔離原則拆分接口時,首先必須滿足單一職責(zé)原則,將一組相關(guān)的操作定義在一個接口中,且在滿足高內(nèi)聚的前提下,接口中的方法越少越好。
(3)可以在進行系統(tǒng)設(shè)計時采用定制服務(wù)的方式,即為不同的客戶端提供寬窄不同的接口,只提供用戶需要的行為,而隱藏用戶不需要的行為。
六、D依賴倒置原則DIP
Dependency-Inversion Principle 要依賴抽象,而不要依賴具體的實現(xiàn), 具體而言就是高層模塊不依賴于底層模塊,二者共同依賴于抽象。抽象不依賴于具體,具體依賴于抽象。
1、定義
高層模塊不應(yīng)該依賴低層模塊,它們都應(yīng)該依賴抽象。抽象不應(yīng)該依賴于細節(jié),細節(jié)應(yīng)該依賴于抽象。簡單的說,依賴倒置原則要求客戶端依賴于抽象耦合。原則表述:
(1)抽象不應(yīng)當(dāng)依賴于細節(jié);細節(jié)應(yīng)當(dāng)依賴于抽象;
(2)要針對接口編程,不針對實現(xiàn)編程。
2、原則分析
(1)如果說開閉原則是面向?qū)ο笤O(shè)計的目標,依賴倒轉(zhuǎn)原則是到達面向設(shè)計"開閉"原則的手段..如果要達到最好的"開閉"原則,就要盡量的遵守依賴倒轉(zhuǎn)原則. 可以說依賴倒轉(zhuǎn)原則是對"抽象化"的最好規(guī)范! 我個人感覺,依賴倒轉(zhuǎn)原則也是里氏代換原則的補充..你理解了里氏代換原則,再來理解依賴倒轉(zhuǎn)原則應(yīng)該是很容易的。
(2)依賴倒轉(zhuǎn)原則的常用實現(xiàn)方式之一是在代碼中使用抽象類,而將具體類放在配置文件中。
(3)類之間的耦合:零耦合關(guān)系,具體耦合關(guān)系,抽象耦合關(guān)系。依賴倒轉(zhuǎn)原則要求客戶端依賴于抽象耦合,以抽象方式耦合是依賴倒轉(zhuǎn)原則的關(guān)鍵。
3、例子1
理解這個依賴倒置,首先我們需要明白依賴在面向?qū)ο笤O(shè)計的概念:
依賴關(guān)系(Dependency):是一種使用關(guān)系,特定事物的改變有可能會影響到使用該事物的其他事物,在需要表示一個事物使用另一個事物時使用依賴關(guān)系。(假設(shè)A類的變化引起了B類的變化,則說名B類依賴于A類。)大多數(shù)情況下,依賴關(guān)系體現(xiàn)在某個類的方法使用另一個類的對象作為參數(shù)。在UML中,依賴關(guān)系用帶箭頭的虛線表示,由依賴的一方指向被依賴的一方。
4、例子2
某系統(tǒng)提供一個數(shù)據(jù)轉(zhuǎn)換模塊,可以將來自不同數(shù)據(jù)源的數(shù)據(jù)轉(zhuǎn)換成多種格式,如可以轉(zhuǎn)換來自數(shù)據(jù)庫的數(shù)據(jù)(DatabaseSource)、也可以轉(zhuǎn)換來自文本文件的數(shù)據(jù)(TextSource),轉(zhuǎn)換后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer)等。
由于需求的變化,該系統(tǒng)可能需要增加新的數(shù)據(jù)源或者新的文件格式,每增加一個新的類型的數(shù)據(jù)源或者新的類型的文件格式,客戶類MainClass都需要修改源代碼,以便使用新的類,但違背了開閉原則?,F(xiàn)使用依賴倒轉(zhuǎn)原則對其進行重構(gòu)。
當(dāng)然根據(jù)具體的情況,也可以將AbstractSource注入到AbstractStransformer,依賴注入的方式有以下三種:
[img]https://ss.csdn.net/p?https://mmbiz.qpic.cn/mmbiz_png/ ... rFZQ/640?wx_fmt=png[/img]
七、合成/聚合復(fù)用原則
(Composite/Aggregate ReusePrinciple ,CARP):要盡量使用對象組合,而不是繼承關(guān)系達到軟件復(fù)用的目的。
1、定義
經(jīng)常又叫做合成復(fù)用原則(Composite ReusePrinciple或CRP),盡量使用對象組合,而不是繼承來達到復(fù)用的目的。
就是在一個新的對象里面使用一些已有的對象,使之成為新對象的一部分;新對象通過向這些對象的委派達到復(fù)用已有功能的目的。簡而言之,要盡量使用合成/聚合,盡量不要使用繼承。
2、原則分析
(1)在面向?qū)ο笤O(shè)計中,可以通過兩種基本方法在不同的環(huán)境中復(fù)用已有的設(shè)計和實現(xiàn),即通過組合/聚合關(guān)系或通過繼承。
繼承復(fù)用:實現(xiàn)簡單,易于擴展。破壞系統(tǒng)的封裝性;從基類繼承而來的實現(xiàn)是靜態(tài)的,不可能在運行時發(fā)生改變,沒有足夠的靈活性;只能在有限的環(huán)境中使用。(“白箱”復(fù)用)
組合/聚合復(fù)用:耦合度相對較低,選擇性地調(diào)用成員對象的操作;可以在運行時動態(tài)進行。(“黑箱”復(fù)用)
(2)組合/聚合可以使系統(tǒng)更加靈活,類與類之間的耦合度降低,一個類的變化對其他類造成的影響相對較少,因此一般首選使用組合/聚合來實現(xiàn)復(fù)用;其次才考慮繼承,在使用繼承時,需要嚴格遵循里氏代換原則,有效使用繼承會有助于對問題的理解,降低復(fù)雜度,而濫用繼承反而會增加系統(tǒng)構(gòu)建和維護的難度以及系統(tǒng)的復(fù)雜度,因此需要慎重使用繼承復(fù)用。
(3)此原則和里氏代換原則氏相輔相成的,兩者都是具體實現(xiàn)"開-閉"原則的規(guī)范。違反這一原則,就無法實現(xiàn)"開-閉"原則,首先我們要明白合成和聚合的概念:
注意:聚合和組合的區(qū)別是什么?
合成(組合):表示一個整體與部分的關(guān)系,指一個依托整體而存在的關(guān)系(整體與部分不可以分開);比如眼睛和嘴對于頭來說就是組合關(guān)系,沒有了頭就沒有眼睛和嘴,它們是不可分割的。在UML中,組合關(guān)系用帶實心菱形的直線表示。
聚合:聚合是比合成關(guān)系的一種更強的依賴關(guān)系,也表示整體與部分的關(guān)系(整體與部分可以分開);比如螺絲和汽車玩具的關(guān)系,螺絲脫離玩具依然可以用在其它設(shè)備之上。在UML中,聚合關(guān)系用帶空心菱形的直線表示。
八、迪米特法則
(Law of Demeter,LoD:系統(tǒng)中的類,盡量不要與其他類互相作用,減少類之間的耦合度。
1、定義
又叫最少知識原則(Least Knowledge Principle或簡寫為LKP)幾種形式定義:
不要和“陌生人”說話。英文定義為:Don't talk to strangers.
只與你的直接朋友通信。英文定義為:Talk only to your immediate friends.
每一個軟件單位對其他的單位都只有最少的知識,而且局限于那些與本單位密切相關(guān)的軟件單位。
簡單地說,也就是,一個對象應(yīng)當(dāng)對其它對象有盡可能少的了解。一個類應(yīng)該對自己需要耦合或調(diào)用的類知道得最少,你(被耦合或調(diào)用的類)的內(nèi)部是如何復(fù)雜都和我沒關(guān)系,那是你的事情,我就知道你提供的public方法,我就調(diào)用這么多,其他的一概不關(guān)心。
2、法則分析
朋友類:在迪米特法則中,對于一個對象,其朋友包括以下幾類:
(1) 當(dāng)前對象本身(this);
(2) 以參數(shù)形式傳入到當(dāng)前對象方法中的對象;
(3) 當(dāng)前對象的成員對象;
(4) 如果當(dāng)前對象的成員對象是一個集合,那么集合中的元素也都是朋友;
(5) 當(dāng)前對象所創(chuàng)建的對象。
任何一個對象,如果滿足上面的條件之一,就是當(dāng)前對象的“朋友”,否則就是“陌生人”。
3、狹義法則和廣義法則:
在狹義的迪米特法則中,如果兩個類之間不必彼此直接通信,那么這兩個類就不應(yīng)當(dāng)發(fā)生直接的相互作用,如果其中的一個類需要調(diào)用另一個類的某一個方法的話,可以通過第三者轉(zhuǎn)發(fā)這個調(diào)用。
狹義的迪米特法則:可以降低類之間的耦合,但是會在系統(tǒng)中增加大量的小方法并散落在系統(tǒng)的各個角落,它可以使一個系統(tǒng)的局部設(shè)計簡化,因為每一個局部都不會和遠距離的對象有直接的關(guān)聯(lián),但是也會造成系統(tǒng)的不同模塊之間的通信效率降低,使得系統(tǒng)的不同模塊之間不容易協(xié)調(diào)。
廣義的迪米特法則:指對對象之間的信息流量、流向以及信息的影響的控制,主要是對信息隱藏的控制。信息的隱藏可以使各個子系統(tǒng)之間脫耦,從而允許它們獨立地被開發(fā)、優(yōu)化、使用和修改,同時可以促進軟件的復(fù)用,由于每一個模塊都不依賴于其他模塊而存在,因此每一個模塊都可以獨立地在其他的地方使用。一個系統(tǒng)的規(guī)模越大,信息的隱藏就越重要,而信息隱藏的重要性也就越明顯。
4、迪米特法則的主要用途:在于控制信息的過載。
在類的劃分上,應(yīng)當(dāng)盡量創(chuàng)建松耦合的類,類之間的耦合度越低,就越有利于復(fù)用,一個處在松耦合中的類一旦被修改,不會對關(guān)聯(lián)的類造成太大波及;
在類的結(jié)構(gòu)設(shè)計上,每一個類都應(yīng)當(dāng)盡量降低其成員變量和成員函數(shù)的訪問權(quán)限;
在類的設(shè)計上,只要有可能,一個類型應(yīng)當(dāng)設(shè)計成不變類;
在對其他類的引用上,一個對象對其他對象的引用應(yīng)當(dāng)降到。
5、例子
外觀模式Facade(結(jié)構(gòu)型)
迪米特法則與設(shè)計模式Facade模式、Mediator模式
系統(tǒng)中的類,盡量不要與其他類互相作用,減少類之間的耦合度,因為在你的系統(tǒng)中,擴展的時候,你可能需要修改這些類,而類與類之間的關(guān)系,決定了修改的復(fù)雜度,相互作用越多,則修改難度就越大,反之,如果相互作用的越小,則修改起來的難度就越小..例如A類依賴B類,則B類依賴C類,當(dāng)你在修改A類的時候,你要考慮B類是否會受到影響,而B類的影響是否又會影響到C類. 如果此時C類再依賴D類的話,呵呵,我想這樣的修改有的受了。
九、Q&A1、面向?qū)ο笤O(shè)計其他原則?
封裝變化;
少用繼承多用組合;
針對接口編程、不針對實現(xiàn)編程;
為交互對象之間的松耦合設(shè)計而努力;
類應(yīng)該對擴展開發(fā)、對修改封閉(開閉OCP原則);
依賴抽象,不要依賴于具體類(依賴倒置DIP原則);
密友原則:只和朋友交談(最少知識原則,迪米特法則);
說明:一個對象應(yīng)當(dāng)對其他對象有盡可能少的了解,將方法調(diào)用保持在界限內(nèi),只調(diào)用屬于以下范圍的方法: 該對象本身(本地方法)對象的組件 被當(dāng)作方法參數(shù)傳進來的對象 此方法創(chuàng)建或?qū)嵗娜魏螌ο螅?/span>
別找我(調(diào)用我) 我會找你(調(diào)用你)(好萊塢原則);
一個類只有一個引起它變化的原因(單一職責(zé)SRP原則);
2、你能解釋一下里氏替換原則嗎?
嚴格定義:如果對每一個類型為S的對象o1,都有類型為T的對象o2,使得以T定義的所有程序P在所有的對象用o1替換o2時,程序P的行為沒有變化,那么類型S是類型T的子類型。
通俗表述:所有引用基類(父類)的地方必須能透明地使用其子類的對象。也就是說子類可以擴展父類的功能,但不能改變父類原有的功能。它包含以下4層含義:
-
子類可以實現(xiàn)父類的抽象方法,但不能覆蓋父類的非抽象方法。
-
子類中可以增加自己特有的方法。
-
當(dāng)子類的方法重載父類的方法時,方法的前置條件(即方法的形參)要比父類方法的輸入?yún)?shù)更寬松。
-
當(dāng)子類的方法實現(xiàn)父類的抽象方法時,方法的后置條件(即方法的返回值)要比父類更嚴格。
3、什么情況下會違反迪米特法則?為什么會有這個問題?
迪米特法則建議“只和朋友說話,不要陌生人說話”,以此來減少類之間的耦合。
4、給我一個符合開閉原則的設(shè)計模式的例子?
開閉原則要求你的代碼對擴展開放,對修改關(guān)閉。這個意思就是說,如果你想增加一個新的功能,你可以很容易的在不改變已測試過的代碼的前提下增加新的代碼。有好幾個設(shè)計模式是基于開閉原則的,如策略模式,如果你需要一個新的策略,只需要實現(xiàn)接口,增加配置,不需要改變核心邏輯。一個正在工作的例子是 Collections.sort() 方法,這就是基于策略模式,遵循開閉原則的,你不需為新的對象修改 sort() 方法,你需要做的僅僅是實現(xiàn)你自己的 Comparator 接口。
5、什么時候使用享元模式(蠅量模式)?
享元模式通過共享對象來避免創(chuàng)建太多的對象。為了使用享元模式,你需要確保你的對象是不可變的,這樣你才能安全的共享。JDK 中 String 池、Integer 池以及 Long 池都是很好的使用了享元模式的例子。