寫了半天居然異常了,暈死,下面先上代碼
1
#include "stdafx.h"
2
#include <iostream>
3
#include "boost\shared_ptr.hpp"
4
using namespace std;
5
using namespace boost;
6
7
//--武器類
8
class weapon
9

{
10
public:
11
void virtual attack() = 0;
12
};
13
14
//--劍
15
class sword:public weapon
16

{
17
public:
18
void attack()
19
{
20
cout<<"using sword to kill 10 enemy per second!"<<endl;
21
}
22
};
23
24
//--弓箭
25
class archery:public weapon
26

{
27
public:
28
void attack()
29
{
30
cout<<"using archery to kill 10 enemy per second!"<<endl;
31
}
32
};
33
34
class general
35

{
36
private:
37
weapon *m_strWeapon;
38
string m_strName;
39
shared_ptr<weapon>myWeapon;
40
public:
41
42
43
general(string strName)
44
:m_strName(strName)
45
{
46
myWeapon = shared_ptr<weapon>(new sword);
47
m_strWeapon = myWeapon.get();
48
}
49
void advance()
50
{
51
cout<<"gogogo!!"<<endl;
52
}
53
void setWeapon(weapon *strWeapon)
54
{
55
m_strWeapon = strWeapon;
56
}
57
58
~general()
59
{
60
61
62
}
63
64
void performAttack()
65
{
66
m_strWeapon->attack();
67
}
68
69
};
70
71
int _tmain(int argc, _TCHAR* argv[])
72

{
73
//生成盧布對象
74
general LvBu("luBu");
75
//前進
76
LvBu.advance();
77
//攻擊
78
LvBu.performAttack();
79
80
shared_ptr<weapon>myWeapon(new archery());
81
//更換武器
82
LvBu.setWeapon(myWeapon.get());
83
//前進
84
LvBu.advance();
85
//攻擊
86
LvBu.performAttack();
87
88
return 0;
89
}
90
91
運行的結果

策略模式。重新看一下它的定義:定義一系列的算法,把它們一個個的封裝起來,并且使它們可以相互轉換。這里所說的一系列的算法封裝就是通過繼承把各自的實現過程封裝到子類中去(我們的例子中是指archery和Sword的實現),而所說的相互轉換就是我們通過設置基類指針而只向不同的子類(我們的例子上是通過SetWeapon來實現的)。
實現時需要注意的問題:
1.什么情況下用public繼承(is-a),什么情況下用組合(has-a)
2.ocp設計原理(open-close principle)
3.生產對象的釋放,shared_ptr的使用和原理。
下面內容摘自
http://liangfen1224.blog.163.com/blog/static/72377647200912411718194/
優先考慮使用策略模式,而不是具體繼承 (Rod)
產生的原因: 屬于對象的行為模式。處理多于一個算法時候,把算法和使用算法的客戶端分開(把行為和環境分割開),從而方便的選擇其中一個算法。
策略模式的用意是針對一組算法,將每一個算法封裝到具有共同接口的獨立的類中,從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發生變化。
假設現在要設計一個販賣各類書籍的電子商務網站的購物車(Shopping Cat)系統。一個最簡單的情況就是把所有貨品的單價乘上數量,但是實際情況肯定比這要復雜。比如,本網站可能對所有的教材類圖書實行每本一元的折扣;對連環畫類圖書提供每本7%的促銷折扣,而對非教材類的計算機圖書有3%的折扣;對其余的圖書沒有折扣。由于有這樣復雜的折扣算法,使得價格計算問題需要系統地解決。
使用策略模式可以把行為和環境分割開來。環境類負責維持和查詢行為類,各種算法則在具體策略類(ConcreteStrategy)中提供。由于算法和環境獨立開來,算法的增減、修改都不會影響環境和客戶端。當出現新的促銷折扣或現有的折扣政策出現變化時,只需要實現新的策略類,并在客戶端登記即可。策略模式相當于"可插入式(Pluggable)的算法"。
程序架構:一個客戶類,一個抽象策略類(接口),若干個具體策略類。由客戶類決定選擇那一個具體類。
定義一系列的算法,把他們一個個封裝起來,并且使它們可相互替換。Strategy模式使算法可獨立于使用它的客戶而變化。
策略模式是對算法的包裝,是把使用算法的責任和算法本身分割開,委派給不同的對象管理。策略模式通常把一個系列的算法包裝到一系列的策略類里面,作為一個抽象策略類的子類。用一句話來說,就是:"準備一組算法,并將每一個算法封裝起來,使得它們可以互換。"
策略又稱做政策(Policy)模式【GOF95】。下面是一個示意性的策略模式結構圖:

這個模式涉及到三個角色:
環境(Context)角色:持有一個Strategy類的引用。
抽象策略(Strategy)角色:這是一個抽象角色,通常由一個接口或抽象類實現。此角色給出所有的具體策略類所需的接口。
具體策略(ConcreteStrategy)角色:包裝了相關的算法或行為。
Strategy模式以下列幾條原則為基礎:
1) 每個對象都是一個具有職責的個體。
2) 這些職責不同的具體實現是通過多態的使用來完成的。
3) 概念上相同的算法具有多個不同的實現,需要進行管理
通過以下步驟,開發人員可以很容易地在軟件中實現策略模型:
1)對策略對象定義一個公共接口。
2)編寫策略類,該類實現了上面的公共接口。
3)策略對象的類中保存一個對策略對象的引用。
4)略對象的類中,實現對策略對象的set和get方法。
例:
public interface DatabaseStrategy {
public void process();
}
public class MysqlDBStrategy implements DatabaseStrategy {
public void process() {
System.out.println("處理Mysql數據庫連接");
}
}
public class OracleDBStrategy implements DatabaseStrategy {
public void process() {
System.out.println("處理Oracle數據庫連接");
}
}
public class DataBaseManager {
public void process(DatabaseStrategy dbStrategy) {
dbStrategy.process();
}
}
public class StrategyClient {
public static void main(String[] args) {
DataBaseManager manager = new DataBaseManager();
MysqlDBStrategy mysql = new MysqlDBStrategy();
manager.process(mysql);
OracleDBStrategy oracle = new OracleDBStrategy();
manager.process(oracle);
}
}
何時使用何種具體策略角色
在學習策略模式時,學員常問的一個問題是:為什么不能從策略模式中看出哪一個具體策略適用于哪一種情況呢?
答案非常簡單,策略模式并不負責做這個決定。換言之,應當由客戶端自己決定在什么情況下使用什么具體策略角色。策略模式僅僅封裝算法,提供新算法插入到已有系統中,以及老算法從系統中"退休"的方便,策略模式并不決定在何時使用何種算法。
策略模式的優點和缺點
策略模式有很多優點和缺點。它的優點有:
1. 策略模式提供了管理相關的算法族的辦法。策略類的等級結構定義了一個算法或行為族。恰當使用繼承可以把公共的代碼移到父類里面,從而避免重復的代碼。
2. 策略模式提供了可以替換繼承關系的辦法。繼承可以處理多種算法或行為。如果不是用策略模式,那么使用算法或行為的環境類就可能會有一些子類,每一個子類提供一個不同的算法或行為。但是,這樣一來算法或行為的使用者就和算法或行為本身混在一起。決定使用哪一種算法或采取哪一種行為的邏輯就和算法或行為的邏輯混合在一起,從而不可能再獨立演化。繼承使得動態改變算法或行為變得不可能。
3. 使用策略模式可以避免使用多重條件轉移語句。多重轉移語句不易維護,它把采取哪一種算法或采取哪一種行為的邏輯與算法或行為的邏輯混合在一起,統統列在一個多重轉移語句里面,比使用繼承的辦法還要原始和落后。
策略模式的缺點有:
1. 客戶端必須知道所有的策略類,并自行決定使用哪一個策略類。這就意味著客戶端必須理解這些算法的區別,以便適時選擇恰當的算法類。換言之,策略模式只適用于客戶端知道所有的算法或行為的情況。
2. 策略模式造成很多的策略類。有時候可以通過把依賴于環境的狀態保存到客戶端里面,而將策略類設計成可共享的,這樣策略類實例可以被不同客戶端使用。換言之,可以使用享元模式來減少對象的數量。
其它
策略模式與很多其它的模式都有著廣泛的聯系。Strategy很容易和Bridge模式相混淆。雖然它們結構很相似,但它們卻是為解決不同的問題而設計的。Strategy模式注重于算法的封裝,而Bridge模式注重于分離抽象和實現,為一個抽象體系提供不同的實現。Bridge模式與Strategy模式都很好的體現了"Favor composite over inheritance"的觀點。
我們現在來看一個場景:我在下班在回家的路上,可以有這幾種選擇,走路、騎車、坐車。首先,我們需要把算法抽象出來:
public interface IStrategy
{
void OnTheWay();
}
接下來,我們需要實現走路、騎車和坐車幾種方式。
public class WalkStrategy : IStrategy
{
public void OnTheWay()
{
Console.WriteLine("Walk on the road");
}
}
public class RideBickStragtegy : IStrategy
{
public void OnTheWay()
{
Console.WriteLine("Ride the bicycle on the road");
}
}
public class CarStragtegy : IStrategy
{
public void OnTheWay()
{
Console.WriteLine("Drive the car on the road");
}
}
最后再用客戶端代碼調用封裝的算法接口,實現一個走路回家的場景:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Arrive to home");
IStrategy strategy = new WalkStrategy();
strategy.OnTheWay();
Console.Read();
}
}
運行結果如下;
Arrive to home
Walk on the road
如果我們需要實現其他的方法,只需要在Context改變一下IStrategy所示例化的對象就可以。
Strategy模式的要點:
1、Strategy及其子類為組件提供了一系列可重用的算法,從而可以使得類型在運行時方便地根據需要在各個算法之間進行切換。所謂封裝算法,支持算法的變化。
2、Strategy模式提供了用條件判斷語句以外的另一中選擇,消除條件判斷語句,就是在解耦合。含有許多條件判斷語句的代碼通常都需要Strategy模式。
3、Strategy模式已算法為中心,可以和Factory Method聯合使用,在工廠中使用配制文件對變化的點進行動態的配置。這樣就使變化放到了運行時。
4、與Template Method相比,Strategy模式的中心跟集中在方法的封裝上
注:
Strategy策略模式是屬于設計模式中 對象行為型模式,主要是定義一系列的算法,把這些算法一個個封裝成單獨的類.
實際整個Strategy的核心部分就是抽象類的使用,使用Strategy模式可以在用戶需要變化時,修改量很少,而且快速.