java面向对象程序设计基础



实验二 Java面向对象程序设计

目录

• 一、单元测试和TDD

  任务一：实现百分制成绩转成“优、良、中、及格、不及格”五级制成绩的功能

  任务二：以TDD的方式研究学习StringBuffer

• 二、面向对象三要素：封装、继承、多态

  任务三：使用StarUML对实验二中的代码进行建模

• 三、设计模式

  任务四：对MyDoc类进行扩充，让其支持Long类，初步理解设计模式

• 附：练习

  任务五：以TDD的方式开发一个复数类Complex

• 四、实验过程中遇到的问题及解决：

  问题一：或者是红色的怎么办？

  问题二：如何写好一个测试单元？怎样使用各种断言方法？

  问题三：如何解决这个“red bar”？

  问题四：Java中StringBuffer的capacity问题探究

• 五、实验体会与总结
• 六、参考资料

一、单元测试和TDD

用程序解决问题时，要学会写以下三种代码：

• 伪代码
• 产品代码
• 测试代码

正确的顺序应为：伪代码（思路）→ 测试代码（产品预期功能）→ 产品代码（实现预期功能），这种开发方法叫“测试驱动开发”（TDD）。TDD的一般步骤如下：

• 明确当前要完成的功能，记录成一个测试列表
• 快速完成编写针对此功能的测试用例
• 测试代码编译不通过（没产品代码呢）
• 编写产品代码
• 测试通过
• 对代码进行重构，并保证测试通过（重构下次实验练习）
• 循环完成所有功能的开发

基于TDD，可以有效避免过度开发的现象，因为我们只需要让测试通过即可。

任务一：实现百分制成绩转成“优、良、中、及格、不及格”五级制成绩的功能

以这个任务为例，我们来对TDD方法进行一次小小的实践。

首先要明白自己的程序需要进行哪些操作？要实现什么目标？伪代码可以帮我们理清思路。

伪代码不需要说明具体调用的方法名，甚至不需要强调你打算使用的语言，理清思路即可。

其次，选择一种语言把伪代码实现，也就成了产品代码。

产品代码是为用户提供的，为了保证正确性，我们需要对自己的程序进行测试，考虑所有可能的情况，来判断结果是否合乎要求。这是我们就需要写测试代码。

根据我们现在的理解，测试代码不就是不断调用，来判断输出是否合乎预期嘛？所以可能会写成下面这种代码：

如果输出，那就代表通过测试咯~

可是...如果输出呢？那事情就很糟糕了。我们需要把每一个测试用例的结果都打印出来，看看到底是哪里出现了该死的“test failed”。本题中的测试用例很少，那如果做大的项目时有成千上万个用例呢？

不用担心！Java中有单元测试工具JUnit来辅助进行TDD，我们用TDD的方式把前面百分制转五分制的例子重写一次，体会一下有测试工具支持的开发的好处。

鼠标放在需要测试的类上单击，出现一个黄色灯泡，点击选择“Create Test”，就可以新建一个测试类啦~

那么，我们可以这么写测试代码：

如果出现问题，IDEA就会提示我们具体是哪一步出错了。比如下面这个实例（我把95分的断言值改成了“良好”，我们知道测试肯定不会通过）：

可以看出，IDEA提示我们，最后一行还有，这下我们明白了，是方法中一个为“良好”的断言错了。这样一来，是不是比上面那种方法方便很多了呢？

当然了，测试代码不能随便一写草草了事，作为开发者的我们必须要考虑得足够周全，尤其是各种边界情况以及非法输入等等。比如本题我们需要添加、等等各种方法进行测试。这些老师的教程里写得很详细，我在此就不赘述了。

任务二：以TDD的方式研究学习StringBuffer

这个任务主要锻炼我们自己写JUnit测试用例的能力。老师在教程里给出的程序如下：

首先我们需要对这个程序进行改写，写成上面的产品代码那种类型的，以便于我们进行测试。

对于这个程序，我们先来看一看哪些方法需要测试？有四个，、、、。在产品代码里，我们需要为这四个方法加上返回值，并与我们的断言进行比较。产品代码如下：

接下来我们需要对调用各种方法的返回值进行猜测。查询API文档可知，对的解释为：“返回此序列中指定索引处的 char 值。第一个 char 值在索引 0 处，第二个在索引 1 处，依此类推，这类似于数组索引。”则返回输入的子字符串的第一个字母在母字符串的位置。这两个看起来都比较好理解，那和呢？我在学习StringBuffer的时候也遇到了这样的困惑，对于这两者之间的区别问题，可以参考我博客的“问题解决”模块。

基于以上的思考和学习，我们可以对各个方法的返回值有一个精确地分析，接下来只需要比较产品代码中的方法与我们的断言值是否相等即可。

出于对老师这篇博客中问题的思考，我设置了长度不同的三个字符串进行测试，代码如下：

可以看到，出现了“green bar”，说明测试通过了，我们对也有了更加深刻的认识。

返回目录

二、面向对象三要素：封装、继承、多态

面向对象(Object-Oriented)的三要素包括：封装、继承、多态。面向对象的思想涉及到软件开发的各个方面，如面向对象分析（OOA）、面向对象设计（OOD）、面向对象编程实现(OOP)。OOA根据抽象关键的问题域来分解系统，关注是什么（what）。OOD是一种提供符号设计系统的面向对象的实现过程，用非常接近问题域术语的方法把系统构造成“现实世界”的对象，关注怎么做（how）,通过模型来实现功能规范。OOP则在设计的基础上用编程语言（如Java）编码。贯穿OOA、OOD和OOP的主线正是抽象。

任务三：使用StarUML对实验二中的代码进行建模

UML是一种通用的建模语言，可以非常直观地表现出各个结构之间的关系。

基于以上学习，我们在UML中实现了类，继承和接口的组合：

当然，UML还可以实现更多更复杂的功能，以上只是一个小小的实践。

返回目录

三、设计模式

面向对象三要素是“封装、继承、多态”，任何面向对象编程语言都会在语法上支持这三要素。如何借助抽象思维用好三要素特别是多态还是非常困难的，S.O.L.I.D类设计原则是一个很好的指导：

• SRP(Single Responsibility Principle,单一职责原则)
• OCP(Open-Closed Principle,开放-封闭原则)
• LSP(Liskov Substitusion Principle,Liskov替换原则)
• ISP(Interface Segregation Principle,接口分离原则)
• DIP(Dependency Inversion Principle,依赖倒置原则)

下面，我们通过具体的题目来学习设计模式。

任务四：对MyDoc类进行扩充，让其支持Long类，初步理解设计模式

OCP是OOD中最重要的一个原则，要求软件实体（类，模块，函数等）应该对扩充开放，对修改封闭。也就是说，软件模块的行为必须是可以扩充的，在应用需求改变或需要满足新的应用需求时，我们要让模块以不同的方式工作；同时，模块的源代码是不可改动的，任何人都不许修改已有模块的源代码。OCP可以用以下手段实现：（1）抽象和继承，（2）面向接口编程。

以这道题为例，已有的支持Int型的代码如下：

如果要求支持Long类，Document类要修改构造方法，这还违反了OCP原则。封装、继承、多态解决不了问题了，这时需要设计模式了：

这样一来，我们只需要、即可使系统支持Long类型，测试代码如下：

我们看到，通过增加了一层抽象层使代码符合了OCP原则，使代码有良好的可扩充性、可维护性。不过，设计模式也不能过度使用，具体在哪些场合应用还要看实际问题。

返回目录

附：练习

任务五：以TDD的方式开发一个复数类Complex

经过以上的学习，我们已经可以基本熟练地应用TDD方法，并跟随TDD方法的节奏设计出伪代码、产品代码和测试代码了，这个任务算是对以上学习内容的回顾。

TDD的编码节奏是：

• 增加测试代码，JUnit出现红条
• 修改产品代码
• JUnit出现绿条，任务完成

首先，我们来写伪代码：

在测试代码中，我们需要对以上提到的方法进行测试。写测试代码时，如果调用了不存在的方法，可以点击这个方法旁边的小灯泡进行修复，这个操作会对应的产品代码中增加一个方法，我们只需要描述这个方法的操作即可，非常方便。

通过不断修复，产品代码也写好了，测试一下能不能出现“green bar”，如果测试不通过再根据提示修改产品代码。

产品代码如下：

返回目录

四、实验过程中遇到的问题及解决

问题一：或者是红色的怎么办？

我和大多数同学一样都遇到了这种情况，是因为没有导入相应的包。参考老师的教程并查阅了相关资料解决了这个问题。

解决方法如下：

首先，进入页面左上角→：

进入之后，根据你的IDEA安装地址导入这两个包就可以了。

问题二：如何写好一个测试单元？怎样使用各种断言方法？

本次实验我们着重学习了如何使用Junit进行单元测试，深入思考一下：单元测试中需要考虑哪些情况呢？

博客单元测试应该测试什么？——Right-BICEP对这个问题进行了较为详细的分析，大致可以总结为：

• 结果是否正确

  这是最基本的，就是看程序运行之后的结构和文档是否一致。

• 边界条件
  • 一致性(Conformance)——值是否符合预期的格式？
  • 有序性(Ordering)——一组值是该有序的，还是该无序的？
  • 区间性(Range)——值是否在一个合理的最大值和最小值的范围之内？
  • 引用、耦合性(Reference)——代码是否引用了一些不受代码本身直接控制的外部因素？
  • 完全伪造或者不一致的输入数据、格式错误的数据、空值或者不完整的值，如0， 0.0， “”， null之类的等等。
• ...

在本次实验的单元测试中，我们大量使用了方法，来判断测试值是否与期望值相等。是应用非常广泛的一个断言，它的作用是比较实际的值和用户预期的值是否一样。

通过学习了解到，还可以使用方法，查看实际值是否满足指定的条件。方法可以实现一般匹配、字符串匹配、数值匹配、collection匹配等等，非常实用。

以下面这个程序为例，我随意写了几个方法，打算使用方法进行测试：

JUnit4.4引入了Hamcrest框架，Hamcest提供了一套匹配符Matcher，这些匹配符更接近自然语言，可读性高，更加灵活。不过需要注意的是，使用方法必须导入相应的类或方法：

得到测试代码如下：

JUnit框架Assert类中还有很多断言方法，比如assertTrue与assertFalse断言、assertNull与assertNotNull断言、assertSame与assertNotSame断言、fail断言等等，还有待我们进一步学习总结。

问题三：如何解决这个“red bar”？

在实验过程中遇到了这样的问题：

在测试类中定义了c1、c2和c3：

并测试复数的减法：

但是测试的时候却出现了“red bar”：

检查产品代码中复数的减法也没有问题：

那错误在哪里呢？

观察错误提示，断言值为但实际输出值为，-5.0恰巧是-3.0 -2.0i实部和虚部的和。好像有点思路了...返回去看产品代码中的方法，注意到当虚部小于零时，我直接进行了操作，而在Java中，这个式子的含义是：先计算的值，再转化为字符串形式，所以会得到错误的输出。将代码改为：，先进行强制类型转换，就解决了这个问题。

问题四：Java中StringBuffer的capacity问题探究

在研究学习StringBuffer的过程中，对有疑惑，查询了API文档了解到：

从API查到capacity的作用是查看StringBuffer的容器容量是多少，刚开始纳闷这个跟length的区别在哪？

于是自己写了一个程序进行测试分析：

打印运行结果：

可以看到，对于空字符串，调用方法初始分配值为16；大小超过16时则扩充容量为34，再次扩充得到70。

那么问题来了！16、34、70是怎么得到的呢？试验了几次还是有点不解。所以直接跟进源码分析。

直接通过new StringBuffer(String str)；时，capacity是str.length+16，从源码可知：

如果小于16则默认容器的大小为16。如果大于16则会调用expandCapacity 函数进行容量的扩展，扩展方式如下：

由源码可以看到扩展的规则是把旧的容量（value的长度）*2+2，然后与现有的比较，如果小于则把现有的容量当做新的，如果大于则用新得到的容量。

所以第一次append时，小于16则不需扩展，如果大于16则会直接扩展到34（16*2+2），比较得到大于append后的长度的话则用34，如果不 是则用append后的长度。

此时capacity的大小等于append后的长度，如果在append的话，若不超过70（34*2+2）的话，此时则capacity为70，如果超过70则继续用第二次append后的总长度。

这样一来，对capacity()的理解就比较透彻了。

返回目录

五、实验体会与总结

这周的实验内容非常丰富，主要学习了如何编写测试代码。

在开发软件的过程中，用户需要实际运行所编写的代码以确保程序的正确性。当软件变得越来越大，再去添加新的功能或做一些新的改动时，就很容易带来新的问题，甚至会使程序无法正常运行。然而要手动的运行代码，测试代码的可行性也是非常枯燥以及非常耗费时间的事情。

为了减少这种手动测试，可以通过创建单元测试来自动完成测试的工作。当修改代码或者添加新功能后，可以执行单元测试来保证代码运行无误。所有测试工作都是由单元测试自动完成的，开发人员所要做的就是看看程序的执行状态。

使用单元测试的另一个理由是实现测试驱动的开发。测试驱动的开发尝试首先写出单元测试，然后完成实际的代码。通过单元测试来提供类的定义，当实际开始编写代码时，用户仅仅需要做的就是具体类的实现，只要单元测试运行通过，代码的实现也将告一段落了。写单元测试的同时，也在同时在做项目的设计，当项目结束后，单元测试还将是不错的文档，何乐而不为呢？

在Java语言中，可以通过JUnit框架进行单元测试。单元测试的实现是很简单的，可以认为它只是判断在某一个时刻，程序运行的值和预期的值是否一致，但在实际的应用的时候是很灵活的，在此介绍JUnit中的一些断言以及JUnit测试框架的使用，使读者能够快速的进入单元测试的领域，更快的进行开发。

JUnit提供了一些辅助函数，用于帮助开发人员确定某些被测试函数是否工作正常。通常而言，把所有这些函数统称为断言，断言是单元测试最基本的组成部分。

除此之外，本次实验还学习了TDD方式、UML建模、S.O.L.I.D原则以及设计模式等等，既加深了对之前内容的理解，又规范了我们的编程流程，对思维也是一个很好的梳理，希望能把这些知识在今后的学习实践中广泛应用。

返回目录

六、参考资料

• 实验二 java面向对象程序设计基础 Java面向对象程序设计
• Intellj IDEA 简易教程
• 积极主动敲代码，使用JUnit学习Java
• UML基础教程
• 单元测试应该测试什么？——Right-BICEP
• junit 测试中各种断言用法
• Junit使用教程（二）
• java单元测试(Junit)
• 菜鸟学Java（二十一）——如何更好的进行单元测试——JUnit
• 关于Java中StringBuffer的capacity问题

版权声明：

本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。

本文网址：https://www.bianchenghao6.com/h6javajc/2004.html