1.設計模式的七大原則
阿新 • • 發佈：2021-01-08
編寫軟體過程中，程式設計師面臨著來自 耦合性，內聚性以及可維護性，可擴充套件性，重用性，靈活性 等多方面的挑戰， 設計模式是為了讓程式(軟體)，具有如下更好的特性
- 程式碼重用性 (即：相同功能的程式碼，不用多次編寫)
- 可讀性 (即：程式設計規範性，便於其他程式設計師的閱讀和理解)
- 可擴充套件性 (即：當需要增加新的功能時，非常的方便，稱為可維護)
- 可靠性 (即：當我們增加新的功能後，對原來的功能沒有影響)
使程式呈現高內聚， 低耦合的特性
那麼一個設計模式在這樣設計的時候,要遵循哪些原則呢,即設計模式為什麼這麼設計的依據, 下面開始介紹,設計模式的 七大原則
- 單一職責原則
- 介面隔離原則
- 依賴倒轉(倒置)原則
- 里氏替換原則
- 開閉原則
- 迪米特法則
- 合成複用原則
1.單一職責原則
對類來說的，即一個類應該只負責一項職責。如類A負責兩個不同職責：職責1，職責2。當職責1需求變更而改變A時，可能造成職責2執行錯誤， 所以需要將類A的粒度分解為A1， A2
案例說明:
方式1:
-
在方式1 的run方法中，違反了單一職責原則,(飛機也在公路上跑)
-
解決的方案非常的簡單，根據交通工具執行方法不同，分解成不同類即可
public class SingleResponsibility1 { public static void main(String[] args) { Vehicle vehicle = new Vehicle(); vehicle.run("摩托車"); vehicle.run("汽車"); vehicle.run("飛機"); } } // 交通工具類 class Vehicle { public void run(String vehicle) { System.out.println(vehicle + " 在公路上執行...."); } }
方式二:
- 遵守單一職責原則
- 但是這樣做的改動很大，即將類分解，同時修改客戶端
- 改進：直接修改Vehicle 類，改動的程式碼會比較少=>方案3
public class SingleResponsibility2 { public static void main(String[] args) { RoadVehicle roadVehicle = new RoadVehicle(); roadVehicle.run("摩托車"); roadVehicle.run("汽車"); AirVehicle airVehicle = new AirVehicle(); airVehicle.run("飛機"); } } class RoadVehicle { public void run(String vehicle) { System.out.println(vehicle + "公路執行"); } } class AirVehicle { public void run(String vehicle) { System.out.println(vehicle + "天空執行"); } } class WaterVehicle { public void run(String vehicle) { System.out.println(vehicle + "水中執行"); } }
方式三:
- 這種修改方法沒有對原來的類做大的修改，只是增加方法
- 這裡雖然沒有在類這個級別上遵守單一職責原則，但是在方法級別上，仍然是遵守單一職責
public class SingleResponsibility3 {
public static void main(String[] args) {
Vehicle2 vehicle2 = new Vehicle2();
vehicle2.run("汽車");
vehicle2.runWater("輪船");
vehicle2.runAir("飛機");
}
}
class Vehicle2 {
public void run(String vehicle) {
//處理
System.out.println(vehicle + " 在公路上執行....");
}
public void runAir(String vehicle) {
System.out.println(vehicle + " 在天空上執行....");
}
public void runWater(String vehicle) {
System.out.println(vehicle + " 在水中執行....");
}
}
總結:
- 降低類的複雜度，一個類只負責一項職責
- 提高類的可讀性，可維護性
- 降低變更引起的風險
- 通常情況下， 我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在程式碼級違反單一職責原則；只有類中方法數量足夠少，可以在方法級別保持單一職責原則
2. 介面隔離原則
Interface Segregation Principle
基本介紹：客戶端不應該依賴它不需要的介面，即一個類對另一個類的依賴應該建立在最小的介面上
舉例說明:
- 類A通過介面Interface1依賴類B，類C通過介面Interface1依賴類D，如果介面Interface1對於類A和類C來說不是最小介面，但是類B和類D必須去實現他們不需要的方法。
- 按隔離原則應當這樣處理：將介面Interface1拆分為獨立的幾個介面，類A和類C分別與他們需要的介面建立依賴關係。也就是採用介面隔離原則
問題程式碼:類 A 通過 Interface1 依賴類 B 類 C 通過 Interface1 依賴類 D，造成類 B 和 類 D 需要去實現他們無需實現的介面
//介面
interface Interface1 {
void operation1();
void operation2();
void operation3();
void operation4();
void operation5();
}
//類B 實現了 所有的介面
class B implements Interface1 {
public void operation1() {
System.out.println("B 實現了 operation1");
}
public void operation2() {
System.out.println("B 實現了 operation2");
}
public void operation3() {
System.out.println("B 實現了 operation3");
}
public void operation4() {
System.out.println("B 實現了 operation4");
}
public void operation5() {
System.out.println("B 實現了 operation5");
}
}
//類D 實現了所有的介面
class D implements Interface1 {
public void operation1() {
System.out.println("D 實現了 operation1");
}
public void operation2() {
System.out.println("D 實現了 operation2");
}
public void operation3() {
System.out.println("D 實現了 operation3");
}
public void operation4() {
System.out.println("D 實現了 operation4");
}
public void operation5() {
System.out.println("D 實現了 operation5");
}
}
// A 類通過介面Interface1 依賴(使用) B類，但是隻會用到1,2,3方法
class A {
Interface1 i = new B();
public void depend1() {
i.operation1();
}
public void depend2() {
i.operation2();
}
public void depend3() {
i.operation3();
}
}
// C 類通過介面Interface1 依賴(使用) D類，但是隻會用到1,4,5方法
class C {
Interface1 i = new D();
public void depend1() {
i.operation1();
}
public void depend4() {
i.operation4();
}
public void depend5() {
i.operation5();
}
}
分析傳統方法的問題，使用介面隔離原則改程序序結構
- 類A通過介面Interface1依賴類B，類C通過介面Interface1依賴類D，如果介面Interface1對於類A和類C來說不是最小介面，但是類B和類D必須去實現他們不需要的方法
- 將介面Interface1拆分為獨立的幾個介面，類A和類C分別與他們需要的介面建立依賴關係。也就是採用介面隔離原則
- 介面Interface1中出現的方法，根據實際情況拆分為三個介面
程式碼:
// 介面1
interface Interface1 {
void operation1();
}
// 介面2
interface Interface2 {
void operation2();
void operation3();
}
// 介面3
interface Interface3 {
void operation4();
void operation5();
}
class B implements Interface1, Interface2 {
public void operation1() {
System.out.println("B 實現了 operation1");
}
public void operation2() {
System.out.println("B 實現了 operation2");
}
public void operation3() {
System.out.println("B 實現了 operation3");
}
}
class D implements Interface1, Interface3 {
public void operation1() {
System.out.println("D 實現了 operation1");
}
public void operation4() {
System.out.println("D 實現了 operation4");
}
public void operation5() {
System.out.println("D 實現了 operation5");
}
}
// A 類通過介面Interface1,Interface2 依賴(使用) B類，但是隻會用到1,2,3方法
class A {
Interface1 i = new B();
public void depend1() {
i.operation1();
}
public void depend2() {
i.operation2();
}
public void depend3() {
i.operation3();
}
}
// C 類通過介面Interface1,Interface3 依賴(使用) D類，但是隻會用到1,4,5方法
class C {
Interface1 i = D();
public void depend1() {
i.operation1();
}
public void depend4() {
i.operation4();
}
public void depend5() {
i.operation5();
}
}
3. 依賴倒轉原則
依賴倒轉(Dependence Inversion Principle )原則是指：
- 高層模組不應該依賴低層模組，二者都應該依賴其抽象
- 抽象不應該依賴細節，細節應該依賴抽象
- 依賴倒轉(倒置)的中心思想是面向介面程式設計
- 依賴倒轉原則是基於這樣的設計理念：相對於細節的多變性，抽象的東西要穩定的多。以抽象為基礎搭建的架構比以細節為基礎的架構要穩定的多。在java中，抽象指的是介面或抽象類，細節就是具體的實現類
- 使用介面或抽象類的目的是制定好規範，而不涉及任何具體的操作，把展現細節的任務交給他們的實現類去完成
程式碼:
public class DependecyInversion {
public static void main(String[] args) {
Person person = new Person();
person.receive(new Email());
}
}
class Email {
public String getInfo() {
return "電子郵件資訊: hello,world";
}
}
//完成Person接收訊息的功能
//方式1分析
//1. 簡單，比較容易想到
//2. 如果我們獲取的物件是 微信，簡訊等等，則新增類，同時Peron也要增加相應的接收方法
//3. 解決思路：引入一個抽象的介面IReceiver, 表示接收者, 這樣Person類與介面IReceiver發生依賴
// 因為Email, WeiXin 等等屬於接收的範圍，他們各自實現IReceiver 介面就ok, 這樣我們就符號依賴倒轉原則
class Person {
public void receive(Email email) {
System.out.println(email.getInfo());
}
}
未遵循依賴倒置原則，Person 類與 Email 類耦合，如果我們還想獲取其他訊息，比如微信、簡訊、QQ 等、則需要新增相應的實現方法
下面進行優化:
public class DependecyInversion {
public static void main(String[] args) {
// 客戶端無需改變
Person person = new Person();
person.receive(new Email());
person.receive(new WeiXin());
}
}
//定義介面
interface IReceiver {
public String getInfo();
}
class Email implements IReceiver {
public String getInfo() {
return "電子郵件資訊: hello,world";
}
}
//增加微信
class WeiXin implements IReceiver {
public String getInfo() {
return "微信資訊: hello,ok";
}
}
//方式2
class Person {
// 這裡我們是對介面的依賴
public void receive(IReceiver receiver) {
System.out.println(receiver.getInfo());
}
}
引入一個抽象的介面 IReceiver，表示接收者（Email、微信、簡訊、QQ 等），接受者分別實現 IReceiver 介面中的方法，實現各自接收訊息的邏輯，Person 類與 IReceiver 介面發生依賴，達到接收訊息的功能
依賴關係傳遞的三種方式和應用案例
-
介面傳遞
public class DependencyPass { public static void main(String[] args) { // 通過介面傳遞 ChangHong changHong = new ChangHong(); OpenAndClose openAndClose = new OpenAndClose(); openAndClose.open(changHong); } } // 方式1： 通過介面傳遞實現依賴 // 開關的介面 interface IOpenAndClose { public void open(ITV tv); // 抽象方法,接收介面 } // ITV介面 interface ITV { public void play(); } // 長虹電視：實現 ITV 介面 class ChangHong implements ITV { @Override public void play() { System.out.println("長虹電視機，開啟"); } } // 裝置播放類：實現 IOpenAndClose 介面，呼叫介面 IITV 的 play() 方法實現播放功能（通過介面注入） class OpenAndClose implements IOpenAndClose { public void open(ITV tv) { tv.play(); } } -
構造方法傳遞
public class DependencyPass { public static void main(String[] args) { // 通過構造器進行依賴傳遞 ChangHong changHong = new ChangHong(); OpenAndClose openAndClose = new OpenAndClose(changHong); openAndClose.open(); } } // 方式2: 通過構造方法依賴傳遞 interface IOpenAndClose { public void open(); // 抽象方法 } interface ITV { // ITV介面 public void play(); } // 長虹電視：實現 ITV 介面 class ChangHong implements ITV { @Override public void play() { System.out.println("長虹電視機，開啟"); } } class OpenAndClose implements IOpenAndClose { public ITV tv; // 成員變數 public OpenAndClose(ITV tv) { // 通過構造器注入實現了 ITV 介面的物件 this.tv = tv; } public void open() { this.tv.play(); } } -
setter 方式傳遞
public class DependencyPass { public static void main(String[] args) { // 通過setter方法進行依賴傳遞 ChangHong changHong = new ChangHong(); OpenAndClose openAndClose = new OpenAndClose(); openAndClose.setTv(changHong); openAndClose.open(); } } // 方式3 , 通過setter方法傳遞 interface IOpenAndClose { public void open(); // 抽象方法 public void setTv(ITV tv); // 通過 setter 方法注入 } interface ITV { // ITV介面 public void play(); } // 長虹電視：實現 ITV 介面 class ChangHong implements ITV { @Override public void play() { System.out.println("長虹電視機，開啟"); } } class OpenAndClose implements IOpenAndClose { private ITV tv; // 通過 setYv() 方法注入實現了 ITV 介面的物件例項 public void setTv(ITV tv) { this.tv = tv; } public void open() { this.tv.play(); } }
總結：無論通過什麼方法，目的都是要將實現了介面的具體實現類注入到呼叫者類中
依賴倒轉原則的注意事項和細節
- 低層模組儘量都要有抽象類或介面，或者兩者都有，程式穩定性更好
- 變數的宣告型別儘量是抽象類或介面，這樣我們的變數引用和實際物件間，就存在一個緩衝層，利於程式擴充套件和優化
- 繼承時遵循里氏替換原則
4. 里氏替換原則
面向物件中的繼承性思考:
- 繼承包含這樣一層含義：父類中凡是已經實現好的方法， 實際上是在設定規範和契約，雖然它不強制要求所有的子類必須遵循這些契約，但是如果子類對這些已經實現的方法任意修改，就會對整個繼承體系造成破壞。
- 繼承在給程式設計帶來便利的同時，也帶來了弊端。比如使用繼承會給程式帶來侵入性，程式的可移植性降低，增加物件間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，並且父類修改後，所有涉及到子類的功能都有可能產生故障
- 問題提出：在程式設計中，如何正確的使用繼承? => 里氏替換原則
里氏替換原則基本介紹:
- 里氏替換原則(Liskov Substitution Principle)在1988年，由麻省理工學院的以為姓裡的女士提出的。
- 如果對每個型別為T1的物件o1，都有型別為T2的物件o2，使得以T1定義的所有程式P在所有的物件o1都代換成o2時，程式P的行為沒有發生變化，那麼型別T2是型別T1的子型別。換句話說，所有引用基類的地方必須能透明地使用其子類的物件。
- 在使用繼承時，遵循里氏替換原則，在子類中儘量不要重寫父類的方法
- 里氏替換原則告訴我們，繼承實際上讓兩個類耦合性增強了， 在適當的情況下，可以通過聚合，組合，依賴 來解決問題
我們也可以通過提升的方法，來儘量滿足里氏替換原則，假設現在有兩個類，A 類和 B 類，如果 B 類繼承 A 類，需要重寫 A 類中的某些方法，那麼，我們在 A 類 和 B 類之上，再抽取出一個更加通用的父類 Base，讓 A 類和 B 類同時去繼承 Base，這樣 B 類就無須重寫 A 類中的某些方法，達到基類的引用對子類物件透明的效果
程式碼一:
未遵循里氏替換原則，由於子類 B 繼承父類 A 時重寫了 func1() 方法，導致程式中使用多型時，本意是想呼叫重寫前的方法，結果變成了重寫後的方法，所以程式輸出結果和預期不同
public class Liskov {
public static void main(String[] args) {
A a = new A();
System.out.println("11-3=" + a.func1(11, 3));
System.out.println("1-8=" + a.func1(1, 8));
System.out.println("-----------------------");
B b = new B();
System.out.println("11-3=" + b.func1(11, 3));// 這裡本意是求出11-3，結果變成了11+3
System.out.println("1-8=" + b.func1(1, 8));// 這裡本意是求出1-8，結果變成了1+8
System.out.println("11+3+9=" + b.func2(11, 3));
}
}
// A類
class A {
// 返回兩個數的差
public int func1(int num1, int num2) {
return num1 - num2;
}
}
// B類繼承了A
// 增加了一個新功能：完成兩個數相加,然後和9求和
class B extends A {
// 這裡，重寫了A類的方法, 可能是無意識
public int func1(int a, int b) {
return a + b;
}
public int func2(int a, int b) {
return func1(a, b) + 9;
}
}
原因分析與解決方法
- 我們發現原來執行正常的相減功能發生了錯誤。原因就是類B無意中重寫了父類的方法，造成原有功能出現錯誤。在實際程式設計中，我們常常會通過重寫父類的方法完成新的功能，這樣寫起來雖然簡單，但整個繼承體系的複用性會比較差。特別是執行多型比較頻繁的時候
- 通用的做法是：原來的父類和子類都繼承一個更通俗的基類，原有的繼承關係去掉，採用依賴，聚合，組合等關係代替
改進:
將類 B 的級別提升至與類 A 平級，他們有一個共同的父類 Base，這樣就不會出現類 B 重寫類 A 中方法的問題，此時基類的引用能夠透明地使用子類的物件
public class Liskov {
public static void main(String[] args) {
A a = new A();
System.out.println("11-3=" + a.func1(11, 3));
System.out.println("1-8=" + a.func1(1, 8));
System.out.println("-----------------------");
B b = new B();
// 因為B類不再繼承A類，因此呼叫者，不會再func1是求減法
// 呼叫完成的功能就會很明確
System.out.println("11+3=" + b.func1(11, 3));// 這裡本意是求出11+3
System.out.println("1+8=" + b.func1(1, 8));// 這裡本意是求出1+8
System.out.println("11+3+9=" + b.func2(11, 3));
// 使用組合仍然可以使用到A類相關方法
System.out.println("11-3=" + b.func3(11, 3));// 這裡本意是求出11-3
}
}
//建立一個更加基礎的基類
class Base {
// 把更加基礎的方法和成員寫到Base類
}
// A類
class A extends Base {
// 返回兩個數的差
public int func1(int num1, int num2) {
return num1 - num2;
}
}
// B類繼承了A
// 增加了一個新功能：完成兩個數相加,然後和9求和
class B extends Base {
// 如果B需要使用A類的方法,使用組合關係
private A a = new A();
// 這裡雖然方法名是 fun1()，但由於類 B 集成於類 Base，已和類 A 無關
public int func1(int a, int b) {
return a + b;
}
public int func2(int a, int b) {
return func1(a, b) + 9;
}
// 我們仍然想使用A的方法
public int func3(int a, int b) {
return this.a.func1(a, b);
}
}
5. 開閉原則
開閉原則（Open Closed Principle） 是程式設計中最基礎、最重要的設計原則
-
一個軟體實體如類，模組和函式應該對擴充套件開放(對提供方)， 對修改關閉(對使用方)。 用抽象構建框架，用實現擴充套件細節。
-
即,當軟體需要變化時，儘量通過擴充套件軟體實體的行為來實現變化，而不是通過修改已有的程式碼來實現變化。(增加程式碼,無需修改程式碼)
-
程式設計中遵循其它原則，以及使用設計模式的目的就是遵循開閉原則。
開閉原則的案例一
未遵循開閉原則，導致新增一個圖形類時，需要在【使用方 GraphicEditor】中新增很多程式碼
public class Ocp {
public static void main(String[] args) {
// 使用看看存在的問題
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Rectangle());
graphicEditor.drawShape(new Circle());
graphicEditor.drawShape(new Triangle());
}
}
//這是一個用於繪圖的類 [使用方，需使用圖形繪圖]
class GraphicEditor {
// 接收Shape物件，然後根據type，來繪製不同的圖形
public void drawShape(Shape s) {
if (s.m_type == 1)
drawRectangle(s);
else if (s.m_type == 2)
drawCircle(s);
//新增一個圖形時,這裡就需要修改程式碼
else if (s.m_type == 3)
drawTriangle(s);
}
// 繪製矩形
public void drawRectangle(Shape r) {
System.out.println(" 繪製矩形 ");
}
// 繪製圓形
public void drawCircle(Shape r) {
System.out.println(" 繪製圓形 ");
}
// 繪製三角形
public void drawTriangle(Shape r) {
System.out.println(" 繪製三角形 ");
}
}
//Shape類，基類
class Shape {
int m_type;
}
// 具體的圖形為提供方，提供具體的繪圖流程
class Rectangle extends Shape {
Rectangle() {
super.m_type = 1;
}
}
class Circle extends Shape {
Circle() {
super.m_type = 2;
}
}
//新增畫三角形
class Triangle extends Shape {
Triangle() {
super.m_type = 3;
}
}
改進程式碼:
public class Ocp {
public static void main(String[] args) {
// 使用看看存在的問題
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Rectangle());
graphicEditor.drawShape(new Circle());
graphicEditor.drawShape(new Triangle());
graphicEditor.drawShape(new OtherGraphic());
}
}
//這是一個用於繪圖的類 [使用方]
class GraphicEditor {
// 接收Shape物件，呼叫draw方法
public void drawShape(Shape s) {
s.draw();
}
}
//Shape類，基類
abstract class Shape {
int m_type;
public abstract void draw();// 抽象方法
}
class Rectangle extends Shape {
Rectangle() {
super.m_type = 1;
}
@Override
public void draw() {
System.out.println(" 繪製矩形 ");
}
}
class Circle extends Shape {
Circle() {
super.m_type = 2;
}
@Override
public void draw() {
System.out.println(" 繪製圓形 ");
}
}
//新增畫三角形
class Triangle extends Shape {
Triangle() {
super.m_type = 3;
}
@Override
public void draw() {
System.out.println(" 繪製三角形 ");
}
}
//新增一個圖形
class OtherGraphic extends Shape {
OtherGraphic() {
super.m_type = 4;
}
@Override
public void draw() {
System.out.println(" 繪製其它圖形 ");
}
}
改進思路:
- 將draw 方法抽象都父類,由子類實現
- 使用時,不依賴具體實現類,而是呼叫介面的方法,這樣就不用管傳進來的是個什麼實現類
這裡同樣也符合 依賴倒轉原則,不直接依賴實現類而是依賴介面
6. 迪米特原則
迪米特法則的基本介紹
-
一個物件應該對其他物件保持最少的瞭解
-
類與類關係越密切，耦合度越大
-
迪米特法則(Demeter Principle)又叫最少知道原則，即一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類不管多麼複雜，都儘量將邏輯封裝在類的內部。對外除了提供的public 方法，不對外洩露任何資訊
-
迪米特法則還有個更簡單的定義：只與直接的朋友通訊
直接的朋友：每個物件都會與其他物件有耦合關係，只要兩個物件之間有耦合關係，我們就說這兩個物件之間是朋友關係。耦合的方式很多，依賴，關聯，組合，聚合等。其中，我們稱出現成員變數，方法引數，方法返回值中的類為直接的朋友，而出現在區域性變數中的類不是直接的朋友。也就是說，陌生的類最好不要以區域性變數的形式出現在類的內部。
案例
//客戶端
public class Demeter1 {
public static void main(String[] args) {
// 建立了一個 SchoolManager 物件
SchoolManager schoolManager = new SchoolManager();
// 輸出學院的員工id 和 學校總部的員工資訊
schoolManager.printAllEmployee(new CollegeManager());
}
}
//學校總部員工類
class Employee {
private String id;
public void setId(String id) {
this.id = id;
}
public String getId() {
return id;
}
}
//學院的員工類
class CollegeEmployee {
private String id;
public void setId(String id) {
this.id = id;
}
public String getId() {
return id;
}
}
//管理學院員工的管理類
class CollegeManager {
// 返回學院的所有員工
public List<CollegeEmployee> getAllEmployee() {
List<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
for (int i = 0; i < 10; i++) { // 這裡我們增加了10個員工到 list
CollegeEmployee emp = new CollegeEmployee();
emp.setId("學院員工id= " + i);
list.add(emp);
}
return list;
}
}
//學校管理類
//分析 SchoolManager 類的直接朋友類有哪些 Employee、CollegeManager
//CollegeEmployee 不是 直接朋友 而是一個陌生類，這樣違背了 迪米特法則
class SchoolManager {
// 返回學校總部的員工
public List<Employee> getAllEmployee() {
List<Employee> list = new ArrayList<Employee>();
for (int i = 0; i < 5; i++) { // 這裡我們增加了5個員工到 list
Employee emp = new Employee();
emp.setId("學校總部員工id= " + i);
list.add(emp);
}
return list;
}
// 該方法完成輸出學校總部和學院員工資訊(id)
void printAllEmployee(CollegeManager sub) {
// 分析問題
// 1. 這裡的 CollegeEmployee 不是 SchoolManager的直接朋友
// 2. CollegeEmployee 是以區域性變數方式出現在 SchoolManager
// 3. 違反了 迪米特法則
// 獲取到學院員工
List<CollegeEmployee> list1 = sub.getAllEmployee();
System.out.println("------------學院員工------------");
for (CollegeEmployee e : list1) {
System.out.println(e.getId());
}
// 獲取到學校總部員工
List<Employee> list2 = this.getAllEmployee();
System.out.println("------------學校總部員工------------");
for (Employee e : list2) {
System.out.println(e.getId());
}
}
}
說明:
- 有一個學院總部的員工類和 分部的員工類, 對於分部有自己的管理類方法,總部也有對應的管理類,並且可以呼叫分部的管理類
- CollegeEmployee 類不是 SchoolManager 類的直接朋友，而是一個陌生類，但確定義在SchoolManager 類某一個方法的內部, 這樣的設計違背了迪米特法則
改進:
- 上述程式碼中,之所以需要違反迪米特法則,是因為在學校總部管理類中, 操作了分部管理類該乾的事,所以在方法的內部聲明瞭分部員工,
- 而分部員工CollegeEmployee 類不是 總部管理員類 的直接朋友
- 對於迪米特法則, 總部管理員類SchoolManager 對於 預設朋友應該知道的越少越好,可以將列印方法封裝在分部管理員類中
//客戶端
public class Demeter1 {
public static void main(String[] args) {
System.out.println("~~~使用迪米特法則的改進~~~");
// 建立了一個 SchoolManager 物件
SchoolManager schoolManager = new SchoolManager();
// 輸出學院的員工id 和 學校總部的員工資訊
schoolManager.printAllEmployee(new CollegeManager());
}
}
//學校總部員工類
class Employee {
private String id;
public void setId(String id) {
this.id = id;
}
public String getId() {
return id;
}
}
//學院的員工類
class CollegeEmployee {
private String id;
public void setId(String id) {
this.id = id;
}
public String getId() {
return id;
}
}
//管理學院員工的管理類
class CollegeManager {
// 返回學院的所有員工
public List<CollegeEmployee> getAllEmployee() {
List<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
for (int i = 0; i < 10; i++) { // 這裡我們增加了10個員工到 list
CollegeEmployee emp = new CollegeEmployee();
emp.setId("學院員工id= " + i);
list.add(emp);
}
return list;
}
// 輸出學院員工的資訊
public void printEmployee() {
// 獲取到學院員工
List<CollegeEmployee> list1 = getAllEmployee();
System.out.println("------------學院員工------------");
for (CollegeEmployee e : list1) {
System.out.println(e.getId());
}
}
}
//學校管理類
class SchoolManager {
// 返回學校總部的員工
public List<Employee> getAllEmployee() {
List<Employee> list = new ArrayList<Employee>();
for (int i = 0; i < 5; i++) { // 這裡我們增加了5個員工到 list
Employee emp = new Employee();
emp.setId("學校總部員工id= " + i);
list.add(emp);
}
return list;
}
// 該方法完成輸出學校總部和學院員工資訊(id)
void printAllEmployee(CollegeManager sub) {
// 分析問題
// 1. 將輸出學院的員工方法，封裝到CollegeManager
sub.printEmployee();
// 獲取到學校總部員工
List<Employee> list2 = this.getAllEmployee();
System.out.println("------------學校總部員工------------");
for (Employee e : list2) {
System.out.println(e.getId());
}
}
}
核心:
- 迪米特法則的核心是降低類之間的耦合
- 但是注意：由於每個類都減少了不必要的依賴，因此迪米特法則只是要求降低類間(物件間)耦合關係， 並不是要求完全沒有依賴關係
7. 合成複用原則
合成複用原則（Composite Reuse Principle）
原則是儘量使用合成/聚合的方式，而不是使用繼承，即儘量使用 has a 的關係，而不要使用 is a 的關係
8. 設計原則核心思想
- 找出應用中可能需要變化之處， 把它們獨立出來， 不要和那些不需要變化的程式碼混在一起。
- 針對介面程式設計， 而不是針對實現程式設計。
- 為了互動物件之間的鬆耦合設計而努力