1700456511
1700456512
public void testGetPriceBelow40（）{
1700456513
1700456514
super.assertEquals（2400，this.below40NovelBook.getPrice（））；
1700456515
1700456516
}
1700456517
1700456518
//测试大于40的书籍是否是打9折
1700456519
1700456520
public void testGetPriceAbove40（）{
1700456521
1700456522
super.assertEquals（5400，this.above40NovelBook.getPrice（））；
1700456523
1700456524
}
1700456525
1700456526
}
1700456527
1700456528
新增加的类，新增加的测试方法，只要保证新增加类是正确的就可以了。
1700456529
1700456530
2.开闭原则可以提高复用性
1700456531
1700456532
在面向对象的设计中，所有的逻辑都是从原子逻辑组合而来的，而不是在一个类中独立实现一个业务逻辑。只有这样代码才可以复用，粒度越小，被复用的可能性就越大。那为什么要复用呢？减少代码量，避免相同的逻辑分散在多个角落，避免日后的维护人员为了修改一个微小的缺陷或增加新功能而要在整个项目中到处查找相关的代码，然后发出对开发人员“极度失望”的感慨。那怎么才能提高复用率呢？缩小逻辑粒度，直到一个逻辑不可再拆分为止。
1700456533
1700456534
3.开闭原则可以提高可维护性
1700456535
1700456536
一款软件投产后，维护人员的工作不仅仅是对数据进行维护，还可能要对程序进行扩展，维护人员最乐意做的事情就是扩展一个类，而不是修改一个类，甭管原有的代码写得多么优秀还是多么糟糕，让维护人员读懂原有的代码，然后再修改，是一件很痛苦的事情，不要让他在原有的代码海洋里游弋完毕后再修改，那是对维护人员的一种折磨和摧残。
1700456537
1700456538
4.面向对象开发的要求
1700456539
1700456540
万物皆对象，我们需要把所有的事物都抽象成对象，然后针对对象进行操作，但是万物皆运动，有运动就有变化，有变化就要有策略去应对，怎么快速应对呢？这就需要在设计之初考虑到所有可能变化的因素，然后留下接口，等待“可能”转变为“现实”。
1700456541
1700456542
1700456543
1700456544
1700456545
设计模式之禅 [:1700453929]
1700456546
设计模式之禅 6.4 如何使用开闭原则
1700456547
1700456548
开闭原则是一个非常虚的原则，前面5个原则是对开闭原则的具体解释，但是开闭原则并不局限于这么多，它“虚”得没有边界，就像“好好学习，天天向上”的口号一样，告诉我们要好好学习，但是学什么，怎么学并没有告诉我们，需要去体会和掌握，开闭原则也是一个口号，那我们怎么把这个口号应用到实际工作中呢？
1700456549
1700456550
1.抽象约束
1700456551
1700456552
抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其包含三层含义：第一，通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；第三，抽象层尽量保持稳定，一旦确定即不允许修改。还是以书店为例，目前只是销售小说类书籍，单一经营毕竟是有风险的，于是书店新增加了计算机书籍，它不仅包含书籍名称、作者、价格等信息，还有一个独特的属性：面向的是什么领域，也就是它的范围，比如是和编程语言相关的，还是和数据库相关的，等等，修改后的类图如图6-3所示。
1700456553
1700456554
1700456555
1700456556
1700456557
图6-3 增加业务品种后的书店售书类图
1700456558
1700456559
增加了一个接口IComputerBook和实现类Computer-Book，而BookStore不用做任何修改就可以完成书店销售计算机书籍的业务。计算机书籍接口如代码6-8所示。
1700456560