1）乙個物件應該對其他物件保持最少的了解
2）類與類之間關係越密切，耦合度越大
3）迪公尺特法則又叫做最小知道原則，即乙個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類不管多麼複雜，都盡量將邏輯封裝在類的內部，對外除了提供的public方法，不對外洩露任何資訊
4）迪公尺特法則還有個更簡單的定義：只與直接的朋友通訊。
直接的朋友：每個物件都會和其他物件有耦合關係，只要兩個物件之間有耦合關係，我們就說這兩個物件之間是朋友關係。耦合的方式很多，依賴，關聯，組合，聚合等。其中，我們稱出現成員變數，方法引數，方法返回值中的類為直接的朋友，而出現在區域性變數中的類不是直接的朋友。也就是說，陌生的類最好不要以區域性變數的形式出現在類的內部。
//客戶端
public
class
demeter1
}//學校總部員工類
class
employee
public string getid()
}//學院的員工類
class
collegeemployee
public string getid()
}//管理學院員工的管理類
class
collegemanager
return list;}}
//學校管理類
//分析 schoolmanager 類的直接朋友類有哪些 employee、collegemanager
//collegeemployee 不是 直接朋友 而是乙個陌生類，這樣違背了 迪公尺特法則
class
schoolmanager
return list;
}//該方法完成輸出學校總部和學院員工資訊(id)
void
printallemployee
(collegemanager sub)
//獲取到學校總部員工
list
list2 =
this
.getallemployee()
; system.out.
println
("------------學校總部員工------------");
for(employee e : list2)
}}
問題出在這裡：我們在想要輸出所有員工資訊的時候，莫名其妙地出現了乙個叫collegeemployee類的變數：我們知道應該通過學院的管理類來進行輸出學院的人員，但是我們並不負責知道人員的具體型別：在現實生活中，這種情形類似於我們所說的「越級指揮」「微操」等，事實上我們並不希望出現這種高耦合的情況。
因此，我們對**進行這樣的修改：
public
class
demeter1
}//學校總部員工類
class
employee
public string getid()
}//學院的員工類
class
collegeemployee
public string getid()
}//管理學院員工的管理類
class
collegemanager
return list;
}//輸出學院員工的資訊
public
void
printemployee()
}}//學校管理類
//分析 schoolmanager 類的直接朋友類有哪些 employee、collegemanager
//collegeemployee 不是 直接朋友 而是乙個陌生類，這樣違背了 迪公尺特法則
class
schoolmanager
return list;
}//該方法完成輸出學校總部和學院員工資訊(id)
void
printallemployee
(collegemanager sub)
}}
這是乙個理解起來十分簡單的原則，但是在具體的設計之中經常無意或者不得不違反，在後續的設計之中必須要注意這個原則。
設計模式 設計模式原則
1 單一職責原則 srp 乙個類應當只有乙個引起其變化的原因。使用單一職責原則的好處有 1 類的複雜性降低 2 可讀性提高 3 可維護性提高 4 變更引起的風險降低 2 黎克特制替換原則 lsp 在使用父類的地方，可以使用其子類替換。黎克特制替換原則的含義 1 子類必須完全實現父類的方法 2 子類可...
設計模式 七大設計原則
定義 應該有且只有乙個原因，引起類的變更 組合是一種強耦合關係，你我都有共同的生命週期，這種強耦合關係，不如直接使用介面實現 建議 介面一定要做到單一原則，類的設計盡量做到只有乙個原因引起變更 定義 所有使用父類的地方，必須能夠透明的使用其子類，反之不行 子類不能完整地實現父類的方法，或者父類的某些...
設計模式學習筆記七 常用設計模式原則總結
前面學習了一部分建立型模式，發現了乙個比設計模式更重要的東西 設計模式原則。對於設計模式來說，為什麼這個模式要這樣解決這個問題，而另乙個模式要那樣，它們背後都遵循的就是永恆的設計原則。可以說，設計原則是設計模式的靈魂。三大基本物件導向設計原則 1.針對介面程式設計，而不是針對實現程式設計 2。優先使...