1700456311
书籍名称：悲惨世界 书籍作者：雨果 书籍价格：￥35.00元
1700456312
1700456313
书籍名称：金瓶梅 书籍作者：兰陵笑笑生 书籍价格：￥43.00元
1700456314
1700456315
项目投产了，书籍正常销售出去，书店也盈利了。从2008年开始，全球经济开始下滑，对零售业影响比较大，书店为了生存开始打折销售：所有40元以上的书籍9折销售，其他的8折销售。对已经投产的项目来说，这就是一个变化，我们应该如何应对这样一个需求变化？有如下三种方法可以解决这个问题：
1700456316
1700456317
❑修改接口
1700456318
1700456319
在IBook上新增加一个方法getOffPrice（），专门用于进行打折处理，所有的实现类实现该方法。但是这样修改的后果就是，实现类NovelBook要修改，BookStore中的main方法也修改，同时IBook作为接口应该是稳定且可靠的，不应该经常发生变化，否则接口作为契约的作用就失去了效能。因此，该方案否定。
1700456320
1700456321
❑修改实现类
1700456322
1700456323
修改NovelBook类中的方法，直接在getPrice（）中实现打折处理，好办法，我相信大家在项目中经常使用的就是这样的办法，通过class文件替换的方式可以完成部分业务变化（或是缺陷修复）。该方法在项目有明确的章程（团队内约束）或优良的架构设计时，是一个非常优秀的方法，但是该方法还是有缺陷的。例如采购书籍人员也是要看价格的，由于该方法已经实现了打折处理价格，因此采购人员看到的也是打折后的价格，会因信息不对称而出现决策失误的情况。因此，该方案也不是一个最优的方案。
1700456324
1700456325
❑通过扩展实现变化
1700456326
1700456327
增加一个子类OffNovelBook，覆写getPrice方法，高层次的模块（也就是static静态模块区）通过OffNovelBook类产生新的对象，完成业务变化对系统的最小化开发。好办法，修改也少，风险也小，修改后的类图如图6-2所示。
1700456328
1700456329
1700456330
1700456331
1700456332
图6-2 扩展后的书店售书类图
1700456333
1700456334
OffNovelBook类继承了NovelBook，并覆写了getPrice方法，不修改原有的代码。新增加的子类OffNovelBook如代码清单6-4所示。
1700456335
1700456336
代码清单6-4 打折销售的小说类
1700456337
1700456338
public class OffNovelBook extends NovelBook{
1700456339
1700456340
public OffNovelBook（String_name,int_price,String_author）{
1700456341
1700456342
super（_name，_price，_author）；
1700456343
1700456344
}
1700456345
1700456346
//覆写销售价格
1700456347
1700456348
@Override
1700456349
1700456350
public int getPrice（）{
1700456351
1700456352
//原价
1700456353
1700456354
int selfPrice=super.getPrice（）；
1700456355
1700456356
int offPrice=0；
1700456357
1700456358
if（selfPrice＞4000）{//原价大于40元，则打9折
1700456359
1700456360
offPrice=selfPrice*90/100；