实际问题:
由于超市隔三差五就要办促销活动,但每次促销活动的方式不一样,所以需要开发一个软件,营业员只要输入原价再选择活动类型后,就能计算出折扣以后的价钱。
普通人的做法:
mian(){ String input = readLine(); double price = readLine(); switch (input) case "九五折": price = price * 0.95; break; case "满100返50": if(price>=100) price = price - 50; break; case "不打折": break; println("打折后价钱:"+price); }
这样写会有几个问题:
1.若现在增加新的打折方式,就要修改这段代码,这就打破了“开放-封闭”的原则。
2.这段代码不易复用。当这个收银系统的其他地方也需要计算折后价的时候,只能将这段代码复制过去;那如果在维护中发现开发人员把“满100返50”写成了“满10000返50”,这时候就需要改两个地方,非常不便。
所以高级做法是:
1.将这一个个折扣抽象成类,这样方便代码的复用;
2.将对不同折扣的判断从客户程序中转移到被调用类中,从而降低客户程序中代码的复杂度。
高级做法的类图:
1.此时,对促销类型的判断从客户端转移到了Context类的构造函数中,从而用户程序只需要给Context的构造函数传入一个促销名称,Context类中的私有成员变量“促销子类对象”就能够获取该促销类的对象。
2.代码如上图构造之后,要获取折后价,只需要:
double price = new Context("满100返50").contextInterface(521);
策略模式和简单工厂模式的比较:
1.工厂模式中的工厂只负责生产对象,它把对象返回给客户端之后就撒手不管了;你客户端爱对对象干嘛就干嘛;
策略模式中的Context类类似于工厂模式中的Factory类,但有个本质区别:
Context类的构造函数Context(key)也有根据key创建不同的对象的功能,除此之外,Context类中还有一个函数contextInterface,能够调用策略类共有函数,从而客户端只需要一个Context类就能够完成两件事情:1.创建策略类对象、2.调用策略类对象中共有函数。因此,使用策略模式时,用户根本不需要知道策略类们的存在,用户只需要知道一个Context类和每种策略类对应的key,就能执行不同策略的功能了。
策略模式中的策略类是用前提的:
一个个策略类们必须要有一个公有接口,每一个策略类都要实现公有接口的抽象函数,从而Context中的contextInterface()函数就能够调用这个公有函数。
2.工厂模式中工厂能创建两种类型类的对象:
a)一个类它需要创建好几种对象,每种对象的属性值不一样;
b)一个类它需要创建好几种对象,每种对象都是一个父类/接口的子类;
而策略模式创建的策略类只能是第二种,而且所有子类中都必须要有共同的函数,好让Context类的contextInterface()调用。
策略模式的作用:
1.使用了策略模式后,如果需要增加一种策略,那么只需要创建一个实现了Strategy接口的子类,并重写其中的函数,然后在Context的构造函数中增加这种子类的判断。客户端的代码、Context中contextInterface()的代码无需作任何修改。
2.策略模式与简单工厂模式的相似之处:
Context的构造函数、Factory的getBean()都是用来判断创建何种类型的对象的。
工厂模式和策略模式都能够将“客户端对究竟创建何种类型的判断”转移到Factory/Context中,从而减少客户端代码的复杂度,降低服务端与客户端之间的藕合度。