設計模式的七大原則詳解 - IT人
文章推薦指數： 80 %
1 認識設計模式 · 2 單一職責原則 · 3 介面隔離原則 · 4 依賴倒轉原則 · 5 里氏替換原則 · 6 開閉原則 · 7 迪米特法則 · 8 合成複用原則.
Togglenavigation
IT人
IT人
設計模式的七大原則詳解
亞州Asu發表於
2020-07-17
設計模式
1認識設計模式
1.1什麼是設計模式
所謂設計模式，就是對經常出現的軟體設計問題的成熟解決方案。
很多人把設計模式想象成非常高深的概念，實際上設計模式僅僅是對特定問題的一種慣性思維。
筆者見過一些學員喜歡抱著一本設計模式的書研究，以期成為一個“高手”，實際上設計模式的理解必須以足夠的程式碼積累量作為基礎，最好是經歷過某種痛苦，或者正在經歷一種苦痛，就會對設計模式有較深的感受。
1.2設計模式的目的
編寫軟體的過程中，程式設計師面臨著來自耦合性、內聚性以及可維護性、可擴充套件性、重用性、靈活性等多方面的挑戰，設計模式是為了讓程式擁有更好的：
程式碼可重用性。
相同功能的程式碼，不用多次編寫；
可讀性。
便於其他程式設計師的閱讀和理解；
可擴充套件性。
當需要增加新功能時，非常方便；
可靠性。
當增加新的功能後，對原來的功能沒有影響；
使程式呈現高內聚、低耦合的特點。
1.3什麼是設計模式的原則
設計模式原則，其實就是程式設計師在程式設計時，應當遵循的原則，也就是各種設計模式的基礎，即設計模式為什麼這樣設計的依據。
設計模式的七大原則有：
單一職責原則
介面隔離原則
依賴倒置原則
里氏替換原則
開閉原則
迪米特法則
合成複用原則
2單一職責原則
2.1什麼是單一職責原則
對類來說，一個類應該只負責一項職責。
如類A負責兩個不同職責：職責1，職責2，當職責1需求變更而改變類A時，可能造成職責2執行錯誤，所以需要將類A的粒度分解為A1，A2。
2.2應用例項
方案一：
/**
*方式一的run方法中，違反了單一職責原則，
*解決的方案是根據交通工具執行方法不同，分解成不同類即可
*/
publicclassSingleResponsebility1{
publicstaticvoidmain(String[]args){
Vehiclevehicle=newVehicle();
vehicle.run("汽車");
vehicle.run("摩托");
vehicle.run("飛機");
}
}
classVehicle{
publicvoidrun(Stringvehicle){
System.out.println(vehicle+"在公路上跑");
}
}
方案二：
/**
*方案二遵循單一職責原則
*但是這樣做的改動很大，即將類分解，同時修改客戶端
*改進：直接修改Vehicle類，改動的程式碼會比較少
*/
publicclassSingleResponsibility2{
publicstaticvoidmain(String[]args){
Vehicle1vehicle1=newVehicle1();
vehicle1.run("汽車");
Vehicle2vehicle2=newVehicle2();
vehicle2.run("輪船");
Vehicle3vehicle3=newVehicle3();
vehicle3.run("飛機");
}
}
classVehicle1{
publicvoidrun(Stringvehicle){
System.out.println(vehicle+"在地上跑");
}
}
classVehicle2{
publicvoidrun(Stringvehicle){
System.out.println(vehicle+"在水上跑");
}
}
classVehicle3{
publicvoidrun(Stringvehicle){
System.out.println(vehicle+"在天上跑");
}
}
方案三：
/**
*這種修改方法沒有對原來的類做大的修改，只是增加方法
*這裡雖然沒有在類這個級別上遵循單一職責原則，但是在方法級別上，仍然遵守這個原則
*/
publicclassSingleResonsibility3{
publicstaticvoidmain(String[]args){
Vehicle4vehicle4=newVehicle4();
vehicle4.run("汽車");
vehicle4.run2("輪船");
vehicle4.run3("飛機");
}
}
classVehicle4{
publicvoidrun(Stringvehicle){
System.out.println(vehicle+"在地上跑");
}
publicvoidrun2(Stringvehicle){
System.out.println(vehicle+"在水上跑");
}
publicvoidrun3(Stringvehicle){
System.out.println(vehicle+"在天上跑");
}
}
2.3注意事項
降低類的複雜度，一個類只負責一項職責；
提高類的可讀性、可維護性；
降低變更引起的風險；
通常情況下，我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在程式碼級違反單一職責原則：只有類中方法數量足夠少，可以在方法級別儲存單一職責原則。
3介面隔離原則
3.1什麼是介面隔離原則
客戶端不應該依賴它不需要的介面，即一個類對另一個類的依賴應該建立在最小的介面上。
3.2應用例項
如圖，類A通過介面Interface1依賴類B，類C通過介面Interface1依賴類D，如果介面Interface1對於類A和類C來說不是最小介面，那麼類B和類D必須去實現他們不需要的方法。
publicclassSegregation1{
}
//介面
interfaceInterface1{
voidoperation1();
voidoperation2();
voidoperation3();
voidoperation4();
voidoperation5();
}
classBimplementsInterface1{
@Override
publicvoidoperation1(){
System.out.println("B實現了operation1");
}
@Override
publicvoidoperation2(){
System.out.println("B實現了operation2");
}
@Override
publicvoidoperation3(){
System.out.println("B實現了operation3");
}
@Override
publicvoidoperation4(){
System.out.println("B實現了operation4");
}
@Override
publicvoidoperation5(){
System.out.println("B實現了operation5");
}
}
classDimplementsInterface1{
@Override
publicvoidoperation1(){
System.out.println("D實現了operation1");
}
@Override
publicvoidoperation2(){
System.out.println("D實現了operation2");
}
@Override
publicvoidoperation3(){
System.out.println("D實現了operation3");
}
@Override
publicvoidoperation4(){
System.out.println("D實現了operation4");
}
@Override
publicvoidoperation5(){
System.out.println("D實現了operation5");
}
}
classA{
publicvoiddepend1(Interface1i){
i.operation1();
}
publicvoiddepend2(Interface1i){
i.operation2();
}
publicvoiddepend3(Interface1i){
i.operation3();
}
}
classC{
publicvoiddepend1(Interface1i){
i.operation1();
}
publicvoiddepend4(Interface1i){
i.operation4();
}
publicvoiddepend5(Interface1i){
i.operation5();
}
}
按隔離原則應當這樣處理：將介面Interface1拆分為獨立的幾個介面，類A和類C分別與他們需要的介面建立依賴關係。
也就是採用介面隔離原則。
publicclassSegregation2{
publicstaticvoidmain(String[]args){
Aa=newA();
a.depend1(newB());
a.depend2(newB());
a.depend3(newB());
Cc=newC();
c.depend1(newD());
c.depend4(newD());
c.depend5(newD());
}
}
//介面
interfaceInterface1{
voidoperation1();
}
interfaceInterface2{
voidoperation2();
voidoperation3();
}
interfaceInterface3{
voidoperation4();
voidoperation5();
}
classBimplementsInterface1,Interface2{
@Override
publicvoidoperation1(){
System.out.println("B實現了operation1");
}
@Override
publicvoidoperation2(){
System.out.println("B實現了operation2");
}
@Override
publicvoidoperation3(){
System.out.println("B實現了operation3");
}
}
classDimplementsInterface1,Interface3{
@Override
publicvoidoperation1(){
System.out.println("D實現了operation1");
}
@Override
publicvoidoperation4(){
System.out.println("D實現了operation4");
}
@Override
publicvoidoperation5(){
System.out.println("D實現了operation5");
}
}
classA{
publicvoiddepend1(Interface1i){
i.operation1();
}
publicvoiddepend2(Interface2i){
i.operation2();
}
publicvoiddepend3(Interface2i){
i.operation3();
}
}
classC{
publicvoiddepend1(Interface1i){
i.operation1();
}
publicvoiddepend4(Interface3i){
i.operation4();
}
publicvoiddepend5(Interface3i){
i.operation5();
}
}
4依賴倒轉原則
4.1什麼是依賴倒轉原則
依賴倒轉原則是指高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象；依賴倒轉的中心思想是面向介面程式設計。
依賴倒轉原則是基於這樣的設計理念：相對於細節的多變性，抽象的東西要穩定的多。
以抽象為基礎搭建的架構比以細節為基礎的架構要穩定的多。
在java中，抽象指的是介面或者抽象類，細節就是具體的實現類。
使用介面或抽象類的目的是制定好規範，而不涉及任何具體的操作，把展現細節的任務交給他們的實現類去完成。
4.2應用例項
請程式設計完成persion接收訊息的功能。
方案一：
publicclassDependecyInversion{
publicstaticvoidmain(String[]args){
Persionpersion=newPersion();
persion.receive(newEmail());
}
}
classEmail{
publicStringgetInfo(){
return"電子郵件：HelloWorld!!!";
}
}
classPersion{
publicvoidreceive(Emaile){
System.out.println(e.getInfo());
}
}
方案二：
/**
*如果我們獲取的物件是微信、簡訊等等，則新增類，同時Persion也要增加相應的接收方法
*解決思路：引入一個抽象的介面IReceiver，表示接收者，這樣Persion類與介面IReceiver發生依賴
*因為Email、WeChat等等屬於接收的範圍，它們各自實現IReceiver介面就可以，這樣我們就符合依賴倒轉原則
*/
publicclassDependecyInversion2{
publicstaticvoidmain(String[]args){
Persion2persion2=newPersion2();
persion2.receive(newEmail2());
persion2.receive(newWeChat());
}
}
interfaceIReceiver{
publicStringgetInfo();
}
classEmail2implementsIReceiver{
@Override
publicStringgetInfo(){
return"電子郵件：HelloWorld!";
}
}
classWeChatimplementsIReceiver{
@Override
publicStringgetInfo(){
return"微信訊息：Helloweixin";
}
}
classPersion2{
publicvoidreceive(IReceiveri){
System.out.println(i.getInfo());
}
}
4.3依賴傳遞的三種方式
介面傳遞、構造方法傳遞、setter方法傳遞。
//第一種方式：介面傳遞
//開關的介面
interfaceIOpenAndClose{
publicvoidopoen(ITVtv);//抽象方法，接收介面
}
interfaceITV{//ITV介面
publicvoidplay();
}
//實現介面
classOpenAndColseimplementsIOpenAndClose{
@Override
publicvoidopoen(ITVtv){
tv.play();
}
}
//方式二：構造方法傳遞
interfaceIOpenAndClose{
publicvoidopen();//抽象方法
}
interfaceITV{//ITV介面
publicvoidplay();
}
classOpenAndCloseimplementsIOpenAndClose{
publicITVtv;//成員
publicOpenAndClose(ITVtv){//構造方法
this.tv=tv;
}
@Override
publicvoidopen(){
this.tv.play();
}
}
//方式三：setter方法傳遞
interfaceIOpenAndClose{
publicvoidopen();//抽象方法
}
interfaceITV{//ITV介面
publicvoidplay();
}
classOpenAndCloseimplementsIOpenAndClose{
privateITVtv;
publicvoidsetTv(ITVtv){
this.tv=tv;
}
@Override
publicvoidopen(){
this.tv.play();
}
}
4.4注意事項
底層模組儘量都要有抽象類或介面，或者兩者都有，程式穩定性更好。
變數的宣告型別儘量是抽象類或介面，這樣我們的變數引用和實際物件間，就存在一個緩衝層，利於程式擴充套件和優化。
繼承時要遵循里氏替換原則。
5里氏替換原則
5.1什麼是里氏替換原則
關於繼承性的思考和說明
繼承包含這樣一層含義：父類中凡是已經實現好的方法，實際上是在設定規範和契約，雖然它不強制要求所有的子類必須遵循這些契約，但是如果子類對這些已經實現的方法任意修改，就會對整個繼承體系造成破壞。
繼承在給程式設計帶來便利的同時，也帶來了弊端。
比如使用繼承會給程式帶來侵入性，程式的可移植性降低，增加物件間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，並且父類修改後，所有涉及到子類的功能都有可能產生故障。
所以，在程式設計中，如何正確的使用繼承？使用里氏替換原則。
基本介紹
里氏替換原則是由麻省理工學院的一位姓裡的女士在1988年提出的。
如果對每個型別為T1的物件o1，都有型別為T2的物件o2，使得以T1定義的所有程式P在所有的物件o1都帶換成o2時，程式P的行為沒有發生變化，那麼型別T2是型別T1的子型別。
換句話說，所有引用基類的地方必須能透明地使用其子類的物件。
在使用繼承時，遵循里氏替換原則，在子類中儘量不要重寫父類的方法。
里氏替換原則告訴我們，繼承實際上讓兩個類耦合性增強了，在適當情況下，可以通過聚合、組合、依賴來解決問題。
5.2應用例項
一個程式引發的問題和思考。
publicclassLiskow1{
publicstaticvoidmain(String[]args){
Aa=newA();
System.out.println("11-3="+a.func1(11,3));
Bb=newB();
System.out.println("11-3="+b.func1(11,3));//這裡本意是求出11-3
System.out.println("11+3+9="+b.func2(11,3));
}
}
classA{
//重寫了A類的方法，可能是無意識的
publicintfunc1(intnum1,intnum2){
returnnum1-num2;
}
}
classBextendsA{
publicintfunc1(inta,intb){
returna+b;
}
publicintfunc2(inta,intb){
returnfunc1(a,b)+9;
}
}
我們發現原來執行正常的相減功能發生了錯誤，原因就是類B無意中重寫了父類的方法，造成原有功能出現錯誤。
在實際程式設計中，我們常常會通過重寫父類的方法完成新的功能，這樣寫起來雖然簡單，但整個繼承體系的複用性會比較差，特別是執行多型比較頻繁的時候。
通用的做法是：原來的父類和子類都繼承一個更通俗的基類，原有的繼承關係去掉，採用依賴、聚合、組合等關係替代。
publicclassLiskow{
publicstaticvoidmain(String[]args){
Aa=newA();
System.out.println("11-3="+a.func1(11,3));
Bb=newB();
//因為B類不再繼承A類，因此呼叫者，不會再認為func1是求減法的。
//呼叫完成的功能就會很明確
System.out.println("11+3="+b.func1(11,3));
System.out.println("11+3+9="+b.func2(11,3));
//使用組合仍然可以使用到A類相關方法
System.out.println("11-3="+b.func3(11,3));
}
}
classBase{
//把更加基礎的方法和成員寫到Base類
}
classAextendsBase{
//重寫了A類的方法，可能是無意識的
publicintfunc1(intnum1,intnum2){
returnnum1-num2;
}
}
classBextendsBase{
//如果B需要使用A的方法，使用組合關係
privateAa=newA();
publicintfunc1(inta,intb){
returna+b;
}
publicintfunc2(inta,intb){
returnfunc1(a,b)+9;
}
//如果我們仍然想使用A的方法
publicintfunc3(inta,intb){
returnthis.a.func1(a,b);
}
}
6開閉原則
6.1什麼是開閉原則
開閉原則是程式設計中最基礎、最重要的設計原則。
一個軟體實體如類、模組和函式應該對擴充套件開放（對提供方），對修改關閉（對適用方）。
用抽象構建框架，用實現擴充套件細節。
當軟體需要變化時，儘量通過擴充套件軟體實體的行為來實現變化，而不是通過修改已有的程式碼來實現變化。
程式設計中遵循其他原則，以及使用設計模式的目的就是遵循開閉原則。
6.2應用例項
看一段畫圖程式碼。
publicclassOcp{
publicstaticvoidmain(String[]args){
GraphicEditorgraphicEditor=newGraphicEditor();
graphicEditor.drawShape(newRectangle());
graphicEditor.drawShape(newCircle());
}
}
//這是一個用於繪圖的類
classGraphicEditor{
//接收Shape時物件，然後根據type，來繪製不同的圖形
publicvoiddrawShape(Shapes){
if(s.m_type==1){
drawRectangle(s);
}elseif(s.m_type==2){
drawCircle(s);
}
}
publicvoiddrawRectangle(Shaper){
System.out.println("繪製矩形");
}
publicvoiddrawCircle(Shaper){
System.out.println("繪製圓形");
}
}
//Shape類，基類
classShape{
intm_type;
}
classRectangleextendsShape{
Rectangle(){
super.m_type=1;
}
}
classCircleextendsShape{
Circle(){
super.m_type=2;
}
}
這段程式碼的優點是比較好理解，簡單易操作。
缺點是違反了設計模式的開閉原則，即當我們給類增加新功能的時候，儘量不修改程式碼，或者儘可能少修改程式碼。
比如我們這時要新增加一個圖形種類：三角形，我們需要修改的地方較多。
改進方案：把Shape類做成抽象類，並提供一個抽象的draw方法，讓子類去實現即可，這樣我們有新的圖形種類時，只需要讓新的圖形類繼承Shape，並實現draw方法即可，“使用方”的程式碼就不需要修改，滿足了開閉原則。
publicclassOcp{
publicstaticvoidmain(String[]args){
GraphicEditorgraphicEditor=newGraphicEditor();
graphicEditor.drawShape(newRectangle());
graphicEditor.drawShape(newCircle());
}
}
//這是一個用於繪圖的類
classGraphicEditor{
//接收Shape時物件，然後根據type，來繪製不同的圖形
publicvoiddrawShape(Shapes){
s.draw();
}
}
//Shape類，基類
abstractclassShape{
publicabstractvoiddraw();//抽象方法
}
classRectangleextendsShape{
@Override
publicvoiddraw(){
System.out.println("繪製矩形");
}
}
classCircleextendsShape{
@Override
publicvoiddraw(){
System.out.println("繪製圓形");
}
}
7迪米特法則
7.1什麼是迪米特法則
一個物件應該對其他物件保持最少的瞭解。
類與類關係越密切，耦合度越大。
迪米特法則又叫最少知道原則，即一個類對自己依賴的類知道的越少越好。
也就是說，對於被依賴的類不管多麼複雜，都儘量將邏輯封裝在類的內部。
對外除了提供public方法，不對外洩露任何資訊。
迪米特法則還有個更簡單的定義：只與直接的朋友通訊。
直接的朋友：每個物件都會與其他物件有耦合關係，只要兩個物件之間有耦合關係，我們就說這兩個物件之間是朋友關係。
耦合的方式很多，依賴，關聯，組合，聚合等。
其中，我們稱出現成員變數，方法引數，方法返回值中的類為直接的朋友，而出現在區域性變數中的類不是直接的朋友。
也就是說，陌生的類最好不要以區域性變數的形式出現在類的內部。
7.2應用例項
程式設計實現以下功能：有一個學校，下屬有各個學院和總部，現要求列印出學校總部員工ID和學院員工的id。
publicclassDemeter{
publicstaticvoidmain(String[]args){
SchoolManagerschoolManager=newSchoolManager();
schoolManager.printAllEmployee(newCollegeManager());
}
}
//學校總部員工
classEmployee{
privateStringid;
publicStringgetId(){
returnid;
}
publicvoidsetId(Stringid){
this.id=id;
}
}
//學院員工
classCollegeEmployee{
privateStringid;
publicStringgetId(){
returnid;
}
publicvoidsetId(Stringid){
this.id=id;
}
}
//管理學院員工的類
classCollegeManager{
//返回學院的所有員工
publicList
按照迪米特法則，應該避免出現非直接朋友關係的耦合。
對程式碼按照迪米特法則進行改進如下：
publicclassDemeter{
publicstaticvoidmain(String[]args){
SchoolManagerschoolManager=newSchoolManager();
schoolManager.printAllEmployee(newCollegeManager());
}
}
//學校總部員工
classEmployee{
privateStringid;
publicStringgetId(){
returnid;
}
publicvoidsetId(Stringid){
this.id=id;
}
}
//學院員工
classCollegeEmployee{
privateStringid;
publicStringgetId(){
returnid;
}
publicvoidsetId(Stringid){
this.id=id;
}
}
//管理學院員工的類
classCollegeManager{
//返回學院的所有員工
publicList
但是注意：由於每個類都減少了不必要的依賴，因此迪米特法則只是要求降低類間（物件間）耦合關係，並不是要求完全沒有依賴關係。
8合成複用原則
8.1什麼是合成複用原則
合成複用原則就是儘量使用合成/聚合的方式，而不是使用繼承。
設計原則的核心思想
找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的程式碼混在一起；
針對介面程式設計，而不是針對實現程式設計；
為了互動物件之間的鬆耦合設計而努力。
相關文章
設計模式學習
2020-11-21
設計模式
記一次使用策略模式優化程式碼的經歷
2020-11-21
技術方案設計的方法
2020-11-21
百分制成績轉換為五級分製成績（8分）題目內容：編寫程式，輸入一個百分制成績，輸出所對應的成績等級“A”、“B”、“C”、“D”、“E”。
(使用switch語句）轉換原則為：
2020-11-21
網路程式設計初學
2020-11-21
四種設計模式詳解
2020-11-21
設計模式
Java網路程式設計--UDP傳送接收資料
2020-11-21
Java
043-socket程式設計傳送GET請求
2020-11-21
Spark3.0.1各種叢集模式搭建
2020-11-21
Spark
PHP實現觀察者模式SplSubjectSplObserverSplObjectStorage
2020-11-21
PHP
《Java程式設計邏輯》第3章類的基礎
2020-11-22
Java
Java設計模式-17、直譯器模式-自定義語言的實現
2020-11-22
Java設計模式
650【畢設課設】基於微控制器大氣壓監測報警系統電路方案設計
2020-11-22
同步模式（Synchronous）
2020-11-22
非同步模式（Asynchronous）
2020-11-22
遊戲程式設計模式學習：第一章命令模式
2020-11-22
設計模式
簡單工廠模式、工廠方法模式和抽象工廠模式有何區別？
2020-11-22
基於Java的Socket類Tcp網路程式設計實現實時聊天互動程式(一)：QQ聊天介面的搭建
2020-11-22
Java
代理模式詳解
2020-11-22
最新文章
FlexJobs：遠端工作調查
動畫合成小技巧！CSS實現動感的倒數計時效果
WebGL實踐之半透陰影
通過docker學習nginx，附全部配置及API測試，可使用apifox直接開啟
個推大資料降本提效實戰分享-Q&A精選
雲上有AI，讓地球科學研究更省力
👨💻Mybatis原始碼我搞透了，面試來問吧！寫了134個原始碼類，1.03萬行程式碼！
一個月後，我們又從MySQL雙主切換成了主-從！
部落格園主題美化（僅相容Markdown）
【docker專欄4】使用docker安裝nginx提供web服務
Oracle歸檔日誌暴增排查優化
mac軟體序列號機器人：KCNScrewforMac
延伸文章資訊
- 1物件導向程式設計基本原則- SOLID
不論是上面那些出自於「Agile Software Development」這本書的五項原則或是本書的主題「設計模式」，都是前人在軟體開發過程中所累積的經驗心得，可以說是學習寫程式的內功 ...
- 2设计模式原则· GitBook
设计模式原则 · 写在前面 · 设计的六大原则 · 依赖倒置原则(Dependence Inversion Principle) · 接口隔离原则(Interface Segregation P...
- 3設計模式6大設計原則 - 程式前沿
設計模式6大設計原則 · 1. 單一職責原則 · 2. 里氏替換原則 · 3. 依賴倒置原則 · 4. 介面隔離原則 · 5. 迪米特法則 · 6. 開閉原則.
- 4SOLID 設計原則. 當工程師大概半年左右的時間 - Medium
設計模式：SOLID Principles 物件導向原則. 當工程師大概半年左右的時間，在工作的過程中慢慢理解到設計模式的重要性，過去總是以能快速實作功能為第 ...
- 5设计模式概念和七大原则 - 腾讯云
