示例切入(鴨子游戲)
- 游戲中會有各種鴨子,一邊游泳,一邊咕咕叫
- 設計了一個鴨子的抽象基類,并讓各種鴨子繼承此基類
- 如果讓鴨子飛,怎么辦?
-
問題
- 并非所有的鴨子都能飛,在基類中增加fly會導致所有的子類都具備fly,連那些不該具備fly的子類也無法排除
- 非常粗暴的解決辦法就是每個子類都要仔細判斷是否要覆寫相關邏輯,比如不會飛的鴨子那么覆寫fly方法,什么事情都不做即可;如果遇到不是咕咕叫的鴨子,則覆寫quack方法
-
繼承的缺點
- 代碼在多個子類中重復
- 很難知道所有鴨子的全部行為
- 運行時的行為不容易改變
- 改變會牽一發動全身
- 每當新增新的鴨子子類,需要被迫檢查并可能需要覆蓋fly和quack方法--噩夢啊
-
使用接口
- 把fly從基類中抽出來,放進一個Flyable接口,只有會飛的鴨子才實現此接口;同樣的方式,設計一個Quackable接口,因為并非所有鴨子都會叫
-
問題
- 解決了一部分問題,不會再有“會飛的橡皮鴨(繼承方式)”
- 但無法進行代碼復用-如后續幾十個能飛的鴨子的飛行邏輯一致,不但每一個子類都需要寫一遍(大量重復的代碼)而且如果修改飛行邏輯的話,則需要全部都修改一遍
-
歸零
- 使用繼承不能很好的解決問題,鴨子的行為在子類不斷的改變并且讓所有的子類都有這些行為是不恰當的
- 使用Flyable和Quackable接口解決了一部分問題,只有會飛的鴨子才會實現Flyable.但是Java接口不具有實現代碼,所有實現接口無法達到達到代碼的復用
-
設計原則
- 找出應用中可能需要變化之處,把他們獨立出來,不要和那些不需要變化的代碼混在一起
- 把變化的部分取出并封裝起來,以便以后可輕易的改動或擴充此部分而不影響不需要變化的的其他部分
- 分開變化和不會變化的部分
- 面向接口編程,而不是面向實現編程
- 飛行行為和咕咕叫行為已經和鴨子類無關了
- 整合
- 最終版本
- 多用組合,少用繼承
S.O.L.I.D 面向對象設計五大基本原則
-
S-單一職責原則
- 一個類應該只有一項工作
- 如計算類只負責計算,而不負責展示,展示需要交由單獨的展示類進行處理
-
O-開放封閉原則
- 對擴展開放,對修改關閉
- 一個類無需修改類本身卻容易擴展
- 如計算類中的計算圖形面積方法大量的if/else,增加圖形要增加大量的if/else-改由圖形本身去計算
-
L-里氏替換原則
- 每一個子類或派生類應該可以替換它們基類或父類
-
I-接口隔離原則
- 不應強迫客戶端實現一個它用不上的接口,或是說客戶端不應該被迫依賴它們不使用的方法
-
D-依賴反轉原則
- 依靠抽象而不是具體實現。它表示高層次的模塊不應該依賴于低層次的模塊,它們都應該依賴于抽象
面向模式的軟件架構
-
架構模式
- Layers/Pipes and Filters/Blackboard/Microkernel/BrokerMVC/PACReflection
- Whole-Part/Master-Slave/Proxy/Command Processor/View Handler/Forwarder-Receiver/Client-Dispatcher-Server/publisher-subscriber/
- Reactor/Proactor/Acceptor-Connector/Aysnchronous Completion Token/Active Object/Thread-Speific Storage
- Loopup/Lazy Acquisition/Caching/Pooling/Resouce Lifecycle Manager/
-
設計模式
- The 23 Gang of Four Design Patterns
-
Creational Patterns
- Abstract Factory/Builder/Factory Method/Prototype/Singleton
-
Structural Patterns
- Adapter/Bridge/Composite/Decorator/Facade/Flyweight/Proxy
-
Behavioral Patterns
- Chain of Resp/Command/Interpreter/Iterator/Mediator/Memento/Observer/State/Strategy/Template/Visitor
-
成例
- 特定語言的,如引用計數(CounterPointer)
- 抽象、封裝、信息隱藏、模塊化、分離關注點、耦合與內聚、充分-完整-簡單、策略與實現分離、接口與實現分離、單個引用點、分而治之
- landon:抽象(個人認為寫代碼最高境界就是抽象)、解耦、開閉
JDK源代碼淺析
- 經典的集合框架
ref
- 《Head First Design Patterns》
- 《Pattern-Oriented Software Architecture》