溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
策略模式
問題的描述：
需求：開發一個鴨子游戲，能游泳，有外觀，實現類圖如下：
增加的需求：
1. 加入飛行功能
2. 加入呱呱叫的功能。。。等等，暫時的解決方式如下：
上線后出現了些問題：
1. 所有的鴨子都能叫嗎？木頭鴨子呢？
2. 所有的鴨子都能飛嗎？木頭鴨子呢？橡皮鴨子呢？
總結下，使用繼承的缺點：
代碼在多個子類中重復
運行時的行為不容易改變
很難知道鴨子的全部行為
改變會牽一發動全身，造成其他鴨子不想要的改變
。。。
好吧，我們引入接口來進一步修改，類圖如下：
問題已經解決了，但是鴨子子類有40多種，我們修改fly方法，難道修改40種樣本？以后的維護的坑有點大哦！
總結下，這種方式的缺點：
代碼在多個子類中重復
維護成本提高（有40個子鴨子類，要修改fly方法需要改40次？）
。。。
問題不斷，我們用設模式來解決這個問題，先看看定義：策略模式：定義算法族，分別封裝起來，它們之間可以互相替換，此模式讓算法的變化獨立于使用算法的客戶。
好，我們修改下，類圖如下：
我們用這個模式解決了：
1. 鴨子行為的各種各樣性（子類行為和超類沒有直接的關系了，添加刪除行為不影響繼承體系）
2. 代碼重用，維護問題（子類太多時修改行為特別麻煩，代碼重復，只修改算算法組就搞定）
3. 動態修改行為（Setter和Getter方法來靈活配置行為）
4. 。。。
這章我們學到的設計原則：
設計原則1： 封裝變化（找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起）。
設計原則2： 針對接口編程，而不是針對實現類
設計原則3： 多用組合，少用繼承
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
