使用场景
创新互联公司主要从事成都做网站、成都网站制作、网页设计、企业做网站、公司建网站等业务。立足成都服务成华,10余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:13518219792
状态模式:当对象的行为随对象的状态的改变而改变时,我们为了解耦多重判断条件,封装行为的变化,可以定义一个抽象的状态类,提供对象行为接口。具体与状态相关的行为,由它的子类去实现。
策略模式:“策略”二字等同于算法,当现实系统中需要对算法动态指定,并且可以互相替换,可以抽象出算法的调用接口,具体的算法实现由具体的策略角色去实现,根据里氏替换原则,任何出现父类的地方都可以使用它的子类去替换,这样符合我们的业务需求。
比较
虽然两者都是抽象出父类规范调用接口,具体的行为由子类实现,环境对象同时包含父类的引用,但是这两者模式应用的场景完全不同。例如:你去ATM机取款,如果你的账户处于冻结状态,就不能正常取款。这里你的银行账户至少有两个状态就是冻结与非冻结。这样的业务解决方案你应该不会想到用策略模式去解决。又如商场打折,有很多打折的策略,儿童用品打7折,老人用品打5折,这个问题不会跟状态模式扯上关系吧,这里商品你不能说有老人状态和儿童状态!
ATM取款案例分析
设计到的角色:取款人、账户、ATM机。
用例图
这边简单起见,就分析取款用例。
基本事件路径
(1) 取款人插入银行卡,输入密码;
(2) 选择取款操作,输入取款金额;
(3) 等待出钞,取款。
在这个用例中,如果取款人账户已冻结,就发生一个可选事件路径,取款用例就被终止。
关键的业务需求是用户取款事实,所以领域建模可以从标识取款和取款人这两个类开始。这边考虑到取款人不仅有取款这个用例,我们将取款泛化成交易。
建模
用例实化
取款:基本事件路径的实化。
细化领域模型
这边引入了ATMSystem这个边界对象作为控制器负责与用户交互(与用户交互的ATM操作界面),Trade是负责处理用户交易的类。
取款人插入银行卡输入密码,ATMSystem负责将验证账户信息的消息传递给Trade交易类,Trade根据传过来的账户密码验证用户是否存在,然后将处理结束的消息传递给ATMSystem这个边界对象反映给用户。
分析模型中的一些类
取款设计——应用状态模式
账户的状态分为冻结状态和激活状态。账户在激活的状态下可以进行交易,而在冻结状态下不能做任何交易。在账户验证的时候,应该返回当前账户的状态,如果账户处于冻结状态,当取款人进行取款操作的时候直接返回错误提示信息。状态图表示如下:
取款应用状态模式结构图:
在验证账户阶段,如果账户处于冻结状态,则直接返回DeadAccount谢绝一切交易,否则返回ActiveAccount处理后面的交易。
示意代码:
这边为了简单实现,省去了ATMSystem这个边界对象。
用户账号信息抽象类
- ///
- /// 用户账号信息
- ///
- public abstract class Account
- {
- ///
- /// 账号
- ///
- private string account;
- ///
- /// 密码
- ///
- private string pwd;
- public abstract decimal getBalance(decimal d);
- }
冻结账号类
- ///
- /// 冻结账户类
- ///
- public class DeadAccount:Account
- {
- public override decimal getBalance(decimal d)
- {
- return 0;
- }
- }
激活账户类
- ///
- /// 激活账户类
- ///
- public class ActiveAccount:Account
- {
- public override decimal getBalance(decimal d)
- {
- return d;
- }
- }
交易类
- ///
- /// 交易类 负责用户交易处理的类
- ///
- public class Trade
- {
- ///
- /// 保存用户账号信息
- ///
- private Account account;
- public Account VolidateLogin(Account a)
- {
- //query the database to validate the user exists
- //For Example
- this.account = new DeadAccount();
- return this.account;
- }
- ///
- /// 商业逻辑 取款
- ///
- ///
- ///
- public decimal GetBalance(decimal d)
- {
- return this.account.getBalance(d);
- }
- }
用户类
- ///
- /// 取款人
- ///
- public class User
- {
- ///
- /// 用户账号信息
- ///
- private Account account;
- ///
- /// 交易处理类
- ///
- private Trade trade;
- public User(Account a, Trade t)
- {
- this.account = a;
- tthis.trade = t;
- }
- ///
- /// 用户登录类
- ///
- public void Login()
- {
- trade.VolidateLogin(account);
- }
- ///
- /// 取款
- ///
- ///
- ///
- public decimal GetBalance(decimal d)
- {
- return trade.GetBalance(d);
- }
- }
客户端代码
- class Client
- {
- static void Main(string[] args)
- {
- //开始用户取款,默认是激活账户
- ActiveAccount aa = new ActiveAccount();
- Trade t = new Trade();
- User u = new User(aa,t);
- //先登录,后取款
- u.Login();
- Console.WriteLine(u.GetBalance(100));
- Console.ReadLine();
- }
- }
用户必须先登录(插入银行卡,输入密码,点确定),才能选择取款业务(选择取款)。登录之后,返回的账号对象作为trade类成员,当进行取款业务的时候直接引用该账号成员获得取款信息。如果该账号属于冻结账号,则直接返回0。否则返回取款的值。
商品折扣案例
案例描述:某家超市国庆节为了促销,某些类商品打折,比如运动鞋打8折、秋装打9折等,张三去购物为了一双运动鞋、一件秋装、一瓶洗发水。。。,张三买完东西回家,心想今天自己总共“赚”了多少钱?
案例分析:商家对于商品打折可能有很多策略,这里使用策略模式,封装商品打折策略,这样以便以后扩展了打折策略,不用去修改原来的代码,具有很好的灵活性。
模式涉及的角色:
抽象策略角色:通常由一个接口或者抽象实现;
具体策略角色:包装了相关的算法和行为;
环境角色:包含抽象策略角色的引用,最终供用户使用。
商品折扣案例设计图
顾客购物涉及到的角色有:购物车、商品、收银台、抽象策略角色和具体策略角色。
购物车:是摆放商品的容器,提供添加和删除操作;
商品:商品实体,有类型,商品名、价格等属性;
收银台:负责收钱,主要是计算顾客购买所有商品的价格和折扣总额;
抽象策略角色:提供折扣策略接口。
具体策略角色:实现具体折扣算法。
商品折扣示意代码:
- ///
- /// 具体商品类
- ///
- public class goods
- {
- ///
- /// 商品类型
- ///
- public string Type
- {
- set;
- get;
- }
- ///
- /// 商品名称
- ///
- public string Name
- {
- get;
- set;
- }
- ///
- /// 商品价格
- ///
- public decimal Price
- {
- get;
- set;
- }
- }
抽象策略角色
- ///
- /// 抽象策略接口
- ///
- public interface IDiscountStrategy
- {
- decimal GetDiscount(goods g);
- }
具体策略角色
- ///
- /// 秋装打折策略
- ///
- public class AutumnDressDiscountStrategy:IDiscountStrategy
- {
- #region IDiscountStrategy Members
- public decimal GetDiscount(goods g)
- {
- return (decimal)0.9 * g.Price;
- }
- #endregion
- }
- ///
- /// 运动鞋打折策略
- ///
- public class SportShoesDiscountStrategy:IDiscountStrategy
- {
- #region IDiscountStrategy Members
- public decimal GetDiscount(goods g)
- {
- return g.Price * (decimal)0.8;
- }
- #endregion
- }
购物车
|
收银台角色
- ///
- /// 收银台
- ///
- public class CashierDesk
- {
- ///
- /// 购物车
- ///
- private ShoppingCar shoppingCar;
- ///
- /// 策略字典
- ///
- private Dictionary
strategies; - public CashierDesk(ShoppingCar sc, Dictionary
s) - {
- this.shoppingCar = sc;
- this.strategies = s;
- }
- ///
- /// 获得所有商品的价格
- ///
- ///
- public decimal GetTotalPrice()
- {
- return shoppingCar.GoodsList.Sum(p => p.Price);
- }
- ///
- /// 获得所有商品的总的折扣
- ///
- ///
- public decimal GetTotalDiscount()
- {
- decimal sum = 0;
- IDiscountStrategy idiscountStrategy;
- foreach (goods g in shoppingCar.GoodsList)
- {
- idiscountStrategy=strategies.SingleOrDefault(p => p.Key == g.Type).Value;
- if (idiscountStrategy != null)
- {
- sum += idiscountStrategy.GetDiscount(g);
- }
- }
- return sum;
- }
- }
客户端代码
- class Client
- {
- static void Main(string[] args)
- {
- ShoppingCar sc = new ShoppingCar();
- Dictionary
discountD = new Dictionary (); - //向购物车中加入商品
- sc.AddGoods(new goods {Name="NIKE鞋 ",Price=100,Type="运动鞋" });
- sc.AddGoods(new goods { Name = "秋装", Price = 200, Type = "秋装" });
- sc.AddGoods(new goods { Name = "苹果", Price = 300, Type = "水果" });
- //配置折扣策略
- discountD.Add("运动鞋", new SportShoesDiscountStrategy());
- discountD.Add("秋装", new AutumnDressDiscountStrategy());
- CashierDesk cd = new CashierDesk(sc, discountD);
- //得到所有商品总价
- Console.WriteLine(cd.GetTotalPrice());
- //得到所有商品折扣价
- Console.WriteLine(cd.GetTotalDiscount());
- Console.ReadLine();
- }
- }
策略模式优点与缺点:
优点
封装了算法不稳定性,易于以后业务策略的扩展。
缺点
每种策略对应于一个具体策略角色类,会增加系统需要维护的类的数量。
原文链接:http://www.cnblogs.com/ejiyuan/archive/2012/06/28/2567905.html
名称栏目:设计模式中的策略模式与状态模式
分享路径:http://www.shufengxianlan.com/qtweb/news18/513568.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联