寫這篇文章的目的和上一篇單例模式一樣，策略模式也是一種常用的設計模式，太多的if-else不僅看着不太美觀而且不好維護，對於自己來說也等於復習了一遍策略模式。先說一下策略 模式的定義： 策略模式封裝了算法家族，可以讓彼此之間互相替換，簡單的來說就是比如之前系統調用 ...

平時在開發中避免不了使用大量的if else語句，但過多層的if else對於性能有很大的開銷，類似如下代碼 上邊代碼只是示例，實際情況可能不止4層 策略模式是一種解耦的方法，它對算法進行封裝，使得算法的調用和算法本身分離。使用策略模式客戶端代碼不需要調整，算法之間可以互相替換 ...

通過上圖可以看出策略模式有以下角色構成： 1、抽象策略（Strategy）角色：抽象策略角色由抽象類或接口來承擔，它給出具體策略角色需要實現的接口； 2、具體策略（ConcreteStrategy）角色：實現封裝了具體的算法或行為； 3、場景（Context）角色 ...

首先要明確的說出策略模式會不可避免導致你的代碼類變得很多，如果對應方法邏輯很復雜時可采用，如果邏輯不是很復雜就有點大材小用了。 ...

前言 　　也許我們的代碼中遇到過多重判斷if-else語句，但是這樣的代碼可讀性差，並且當擴展時，違反了“開閉原則”。阿里開發規范中提到的解決方法有：衛語句，策略模式，狀態模式。本文講述的是通過策略模式來解決多重判斷if-else語句問題。 　　github代碼地址：https ...

1. 狀態機基本概念 http://zh.wikipedia.org/wiki/%E6%9C%89%E9%99%90%E7%8A%B6%E6%80%81%E6%9C%BA 狀態存儲關於過去的信息， ...

前言 利用利用策略模式實際開發中 if else 條件判斷過多的問題 比如平時大家是否都會寫類似這樣的代碼： 條件少還好，一旦 else if 過多這里的邏輯將會比較混亂，並很容易出錯。 比如這樣： 摘自 cim 中的一個客戶端命令的判斷條件。 剛開始條件較少，也就 ...

前言 不出意外，這應該是年前最后一次分享，本次來一點實際開發中會用到的小技巧。 比如平時大家是否都會寫類似這樣的代碼： 條件少還好，一旦 else if 過多這里的邏輯將會比較混亂，並很容易出錯。 比如這樣： 摘自 cim 中的一個客戶端命令的判斷條件。 剛開始條件 ...