1700456294
1700456295
（book.getPrice（）/100.0）+“元”）；
1700456296
1700456297
}
1700456298
1700456299
}
1700456300
1700456301
}
1700456302
1700456303
在BookStore中声明了一个静态模块，实现了数据的初始化，这部分应该是从持久层产生的，由持久层框架进行管理，运行结果如下：
1700456304
1700456305
––––书店卖出去的书籍记录如下：–––––––
1700456306
1700456307
书籍名称：天龙八部 书籍作者：金庸 书籍价格：￥32.00元
1700456308
1700456309
书籍名称：巴黎圣母院 书籍作者：雨果 书籍价格：￥56.00元
1700456310
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