- Yet Another Design Pattern
- 先搞清楚
- 設計模式是什麼？
- ＊同一個需求(or 挑戰)寫成程式, 可以有非常多種的寫法, 就像一個相同的作文題目, 寫出來的文章, 卻千變萬化一樣.
- 簡單講, 物件導向程式的 “設計模式” 是介紹你幾種, 好用的類別寫法, 讓你的程式 物件之間 的耦合度降低.
- 軟體界, “物件導向” 裡 “類別” 所謂的 “耦合” (Coupling) 是什麼？
- ＊兩個類別或物件之間關係的緊密程度
- ＊分成 “鬆耦合” (Loose coupling) 跟 “緊耦合” (Tight coupling) 兩種
- 緊耦合 (Tight coupling) 名詞解釋
- 鬆耦合 (Loose coupling)
- ＊程式設計時, 盡量考慮讓物件或模組, 或服務之間, 耦合程度, 降到越低越好 !!
- 什麼叫 “容易測試”？
- ＊容易寫 Unit test 測試程式, 就是容易測試 !!
- 場景ㄧ
先搞清楚
設計模式是什麼？
＊同一個需求(or 挑戰)寫成程式, 可以有非常多種的寫法, 就像一個相同的作文題目, 寫出來的文章, 卻千變萬化一樣.
軟體界, “物件導向” 裡 “類別” 所謂的 “耦合” (Coupling) 是什麼？
＊兩個類別或物件之間關係的緊密程度
＊分成 “鬆耦合” (Loose coupling) 跟 “緊耦合” (Tight coupling) 兩種
緊耦合 (Tight coupling) 名詞解釋
(一)指兩個計算處理，以高度相依的方式完成一計算工作。(二)指二個程式模組邏輯相依度高，即修改一個模組會影響到另一個。(三)指二個電腦，以高度相依的方式進行工作。鬆耦合 (Loose coupling)
剛好相反, 低度相依＊程式設計時, 盡量考慮讓物件或模組, 或服務之間, 耦合程度, 降到越低越好 !!
什麼叫 “容易測試”？
＊容易寫 Unit test 測試程式, 就是容易測試 !!
場景ㄧ
辛巴克 = ["A", "B", "C"]class 員工: def __init__(self, name): self.__name = name def 名字(self): return self.__name def 改名字(self, name): self.__name = name
class 咖啡店面: def __init__(self): self.__全部員工 = [] def add員工(self, employee): self.__全部員工.append(employee) def 所有員工(self): return self.__全部員工 def 解僱(self, employee_name): for e in self.所有員工(): if e.名字() == employee_name: self.__全部員工.remove(e)
辛巴克 = 咖啡店面()a = 員工("A")b = 員工("B")c = 員工("C")辛巴克.add員工(a)辛巴克.add員工(b)辛巴克.add員工(c)print(辛巴克.所有員工())for e in 辛巴克.所有員工(): print(e.名字())class 員工: def __init__(self, name): self.__name = name def 名字(self): return self.__name def 改名字(self, new_name, 雇主): # DI (dependency injection) if 雇主.同意員工改名(self): self.__name = new_name
class 咖啡店面: def __init__(self): self.__全部員工 = [員工("A", self), 員工("B", self), 員工("C", self)] def 所有員工(self): return self.__全部員工 def 同意員工改名(self, employee): return False
"""* 問題一, self.__全部員工 = [員工("A", self), 員工("B", self), 員工("C", self)], 寫死了.* 問題二, 同意員工改名(self, employee):, 可以改用 Strategy Pattern, 讓員工跟咖啡店的互動關係, 可以更容易增加或修改* 問題三, 員工 def __init__(self, name, 雇主): 是否順便讓雇主把它加到 店面的 self.__全部員工 裡.* 問題四, def 改名字(self, name): 是不是改成, def 改名字(self, name, 同意單位), 讓 “咖啡定面" 只是ㄧ種 "同意單位" interface 的子類 就好, 不會讓 "雇主", 跟 "員工" 綁的太緊* 問題五, 咖啡店面, 是不是可以 繼承於 "公司" interface, 讓員工 也可以到別類的公司上班* 還有想到其他問題嗎? ..."""