設計模式 二 策略模式

2021-05-28 05:32:31 字數 1450 閱讀 9087

定義演算法家族,分別封裝起來,讓它們之間可以互相替換,讓演算法變化,不會影響到使用者

good:適合類中的成員以方法為主,演算法經常變動;簡化了單元測試(因為每個演算法都有自己的類,可以通過自己的介面單獨測試。

策略模式和簡單工廠基本相同,但簡單工廠模式只能解決物件建立問題,對於經常變動的演算法應使用策略模式。

bug:客戶端要做出判斷

//策略基類

class coperation

}; //策略具體類—加法類

class addoperation : public coperation

virtual double getresult()

}; class context

double getresult()

}; //客戶端

int main()

return 0; }

策略與工廠結合

good:客戶端只需訪問context類,而不用知道其它任何類資訊,實現了低耦合。

在上例基礎上,修改下面內容

class context

}double getresult()

}; //客戶端

int main()

單一職責原則

就乙個類而言,應該僅有乙個引起它變化的原因。

如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或者抑制這個類完成其它職責能力。這種耦合會導制脆弱的設計,當變化發生時,設計會遭受到意想不到的破壞。

如果你能夠想到多於乙個的動機去改變乙個類,那麼這個類就具有多於乙個的職責。

開放――封閉原則

軟體實體可以擴充套件,但是不可修改。即對於擴充套件是開放的,對於修改是封閉的。面對需求,對程式的改動是通過增加**來完成的,而不是改動現有的**。

當變化發生時,我們就建立抽象來隔離以後發生同類的變化。

開放――封閉原則是物件導向的核心所在。開發人員應該對程式中呈現出頻繁變化的那部分做出抽象,拒絕對任何部分都刻意抽象及不成熟的抽象。

黎克特制代換原則

乙個軟體實體如果使用的是乙個父類的話,那麼一定適用其子類。而且它察覺不出父類物件和子類物件的區別。也就是說:在軟體裡面,把父類替換成子類,程式的行為沒有變化。

子型別必須能夠替換掉它們的父型別。

依賴倒轉原則

抽象不應該依賴細節,細節應該依賴抽象。即針對介面程式設計,不要對實現程式設計。

高層模組不能依賴低層模組,兩者都應依賴抽象。

依賴倒轉原則是物件導向的標誌,用哪種語言編寫程式不重要,如果編寫時考慮的是如何針對抽象程式設計而不是針對細節程式設計,即程式的所有依賴關係都終止於抽象類或介面。那就是物件導向設計,反之那就是過程化設計。

設計模式(二) 策略模式

策略模式 strategy 它定義了乙個演算法家族,分別封裝起來,讓它們之間可以互相替換,此模式讓演算法的變化,不會影響到使用演算法的客戶。現金收費抽象類 abstract class cashsuper 正常收費子類 class cashnormal cashsuper 打折收費子類 class ...

設計模式(二) 策略模式

策略模式定義了演算法家族,分別封裝起來,讓它們之間可以互相替換,此模式讓演算法的變化,不會影響到使用演算法的客戶。我們來實現乙個簡單的商場收銀軟體功能來闡述策略模式 1.我們先來定義乙個收費方式的基類,如下 using system namespace strategy 2.收費方案,如下 usin...

設計模式 (二)策略模式

策略模式 abstract class abstract class strategy 演算法a class concretestrategya extends strategy 演算法b class concretestrategyb extends strategy 演算法c class con...