1700456494
}
1700456495
1700456496
单元测试通过，显示绿条。在单元测试中，有一句非常有名的话，叫做”Keep the bar green to keep the code clean”，即保持绿条有利于代码整洁，这是什么意思呢？绿条就是Junit运行的两种结果中的一种：要么是红条，单元测试失败；要么是绿条，单元测试通过。一个方法的测试方法一般不少于3种，为什么呢？首先是正常的业务逻辑要保证测试到，其次是边界条件要测试到，然后是异常要测试到，比较重要的方法的测试方法甚至有十多种，而且单元测试是对类的测试，类中的方法耦合是允许的，在这样的条件下，如果再想着通过修改一个方法或多个方法代码来完成变化，基本上就是痴人说梦，该类的所有测试方法都要重构，想象一下你在一堆你并不熟悉的代码中进行重构时的感觉吧！
1700456497
1700456498
在书店售书的例子中，增加了一个打折销售的需求，如果我们直接修改getPrice方法来实现业务需求的变化，那就要修改单元测试类。想想看，我们举的这个例子是非常简单的，如果是一个复杂的逻辑，你的测试类就要修改得面目全非。还有，在实际的项目中，一个类一般只有一个测试类，其中可以有很多的测试方法，在一堆本来就很复杂的断言中进行大量修改，难免会出现测试遗漏情况，这是项目经理很难容忍的事情。
1700456499
1700456500
所以，我们需要通过扩展来实现业务逻辑的变化，而不是修改。上面的例子中通过增加一个子类OffNovelBook来完成了业务需求的变化，这对测试有什么好处呢？我们重新生成一个测试文件OffNovelBookTest，然后对getPrice进行测试，单元测试是孤立测试，只要保证我提供的方法正确就成了，其他的我不管，OffNovelBookTest如代码清单6-7所示。
1700456501
1700456502
代码清单6-7 打折销售的小说类单元测试
1700456503
1700456504
public class OffNovelBookTest extends TestCase{
1700456505
1700456506
private IBook below40NovelBook=new OffNovelBook（“平凡的世界”，3000，“路遥”）；
1700456507
1700456508
private IBook above40NovelBook=new OffNovelBook（“平凡的世界”，6000，“路遥”）；
1700456509
1700456510
//测试低于40元的数据是否是打8折
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
[
上一页 ]
[ :1.700456494e+09 ]
[
下一页 ]