## 迪米特原則 最少知識原則
單一職責原則說道:一個對象(方法)只做一件事;那代表著我們要創建更多的對象(方法)來分解一個之前比較大的對象(方法),那分解之后,對象(方法)是小了,好維護好擴展了,但是對象之間的聯系卻越來越多了,有兩個對象非常耦合,怎么辦
**【定義】**
> **最**少知識原則要求我們在設計程序時,應當盡量減少對象之間的交互。如果兩個對象之間不 必彼此直接通信,那么這兩個對象就不要發生直接的相互聯系。常見的做法是引入一個第三者對 象,來承擔這些對象之間的通信作用。如果一些對象需要向另一些對象發起請求,可以通過第三 者對象來轉發這些請求
**【優點】** 減少或消除對象之間的耦合程度,提高復用性
**【缺點】** 需要封裝對象或者引入一個第三者對象來處理兩者之間的聯系,有時候第三者對象會復雜到難以維護
**【應用】** 封裝是廣義上最少知識原則的一種體現,封裝的好處是隱藏內部屬性、方法、實現細節,只拋出指定數據或對象給外界,外界使用封裝對象的對象越少說明聯系就越少。另外一種就是兩個對象很耦合的時候通過引入第三者來處理兩個對象之間的關系
這個demo是我自己編的,大概的意思是一個班級有n個學生,學生有自己的年齡,年齡相等的學生可以做朋友(emmmm,原諒我奇葩的腦洞,還好我沒說性別一樣的才能做朋友,不然要被在座的各位打屎),如果每次新進來一個學生,都要全班一個學生一個學生的問年齡,那太麻煩了,如果老師入學的時候把學生按年齡分批了,那是不是很好找到,這個按年齡分批次就是引入的第三者來處理這個問題,我不知道夠不夠形象啊,但是書上的外觀模式的代碼舉例真的辣雞,不夠形象??
~~~
let nameList = [{
name: 'eason',
age: 1
}, {
name: 'taylor',
age: 3
}, {
name: 'jack',
age: 2
}, {
name: 'yu',
age: 1
}, {
name: 'xixi',
age: 3
}]
let state = {}
let People = (name, age) => {
let that = {}
that.name = name
that.age = age
that.friends = []
return that
}
// bad
for (let n of nameList) {
state[n.name] = new People(n.name, n.age)
}
let jay = new People('jay', 3)
let syz = new People('syz', 2)
let keys = Object.keys(state)
for (let k of keys) {
if (state[k].age === jay.age) {
jay.friends.push(state[k].name)
}
if (state[k].age === syz.age) {
syz.friends.push(state[k].name)
}
}
console.log('jay-friends', jay.friends) // ["jay", "taylor", "xixi"]
//good
let ageList = []
let ageMap = {}
for (let n of nameList) {
state[n.name] = new People(n.name, n.age)
if (ageList.indexOf(n.age) < 0) {
ageList.push(n.age)
ageMap[n.age] = []
ageMap[n.age].push(n.name)
} else {
ageMap[n.age].push(n.name)
}
}
let addPeople = (name, age) => {
ageMap[age] = ageMap[age] || []
ageMap[age].push(name)
return new People(name, age)
}
let jay = addPeople('jay', 3)
let syz = addPeople('syz', 2)
console.log('jay-friends', ageMap[jay.age]) //["taylor", "xixi", "jay"]
console.log('syz-friends', ageMap[syz.age]) //["jack", "syz"]
~~~
- 視覺規范
- 色彩
- 文字
- 偏移
- 圖標
- 列表組件
- 表單組件
- 詳情組件
- 其他組件
- 研發規范
- 編碼規范
- 函數式編程
- 純函數
- 柯里化
- 函數組合
- 函子
- 面向對象編程
- 設計原則
- 單一職責原則
- 里氏替換原則
- 依賴倒置原則
- 接口隔離原則
- 開閉原則
- 迪米特原則
- 組合復用原則
- 設計模式
- 創建型模式
- 工廠模式
- 簡單工廠
- 工廠方法
- 抽象工廠
- 單例模式
- 建造者模式
- 原型模式
- 結構型模式
- 適配器模式
- 橋接模式
- 過濾器模式
- 組合模式
- 裝飾器模式
- 外觀模式
- 享元模式
- 代理模式
- 行為型模式
- 責任鏈模式
- 命令模式
- 解釋器模式
- 迭代器模式
- 中介者模式
- 備忘錄模式
- 觀察者模式
- 狀態模式
- 策略模式
- 模板模式
- 訪問者模式
- 組件設計規范
- 組件文檔編寫規范
- 版本管理規范