一、 实验内容
1. 初步掌握单元测试和TDD
2. 理解并掌握面向对象三要素:封装、继承、多态
3. 初步掌握UML建模
4. 熟悉S.O.L.I.D原则
5. 了解设计模式
二、 实验步骤
【实验一】单元测试
(1) 三种代码
当我们想用程序解决问题时,要会写三种码:伪代码、产品代码、测试代码。
需求:我们要在一个MyUtil类中解决一个百分制成绩转成“优、良、中、及格、不及格”五级制成绩的功能。
先写伪代码,伪代码可以用汉语写,推荐用英语写,伪代码与具体编程语言无关,不要写与具体编程语言语法相关的语句(如用malloc分配内存,这样只能用C语言编程了),伪代码从意图层面来解决问题,最终,伪代码是产品代码最自然的、最好的注释。针对上面的问题,我们可以通过伪代码这样解决:
百分制转五分制:
如果成绩小于60,转成“不及格”
如果成绩在60与70之间,转成“及格”
如果成绩在70与80之间,转成“中等”
如果成绩在80与90之间,转成“良好”
如果成绩在90与100之间,转成“优秀”
其他,转成“错误”
有了伪代码,我们用java语言翻译一下,就是可用的产品代码了,翻译好的MyUtil.java如下:
写了产品代码,我们还要写测试代码,证明自己的代码没有问题。Java编程时,程序员对类实现的测试叫单元测试。类XXXX的单元测试,我们一般写建一个XXXXTest的类,针对MyUtil类我们写一个MyUtilTest.java的测试模块,代码如下:
public class MyUtilTest { public static void main(String[] args) { // 百分制成绩是50时应该返回五级制的“不及格” if(MyUtil.percentage2fivegrade(50) != "不及格") System.out.println("test failed!"); else System.out.println("test passed!"); } }
这里我们设计了一个测试用例(Test Case),测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。测试输入是“50”,预期结果是“不及格”。在Eclipse中运行结果:
只有一组输入的测试是不充分的,我们把一般情况都测试一下,代码如下:
public class MyUtilTest { public static void main(String[] args) { //测试正常情况 if(MyUtil.percentage2fivegrade(55) != "不及格") System.out.println("test failed!"); else if(MyUtil.percentage2fivegrade(65) != "及格") System.out.println("test failed!"); else if(MyUtil.percentage2fivegrade(75) != "中等") System.out.println("test failed!"); else if(MyUtil.percentage2fivegrade(85) != "良好") System.out.println("test failed!"); else if(MyUtil.percentage2fivegrade(95) != "优秀") System.out.println("test failed!"); else System.out.println("test passed!"); } }
下面测试异常情况,输入为负分或大于100的成绩,代码如下:
public class MyUtilTest { public static void main(String[] args) { //测试出错情况 if(MyUtil.percentage2fivegrade(-10) != "错误") System.out.println("test failed 1!"); else if(MyUtil.percentage2fivegrade(115) != "错误") System.out.println("test failed 2!"); else System.out.println("test passed!"); } }
发现负分时与期望不一致,这里有一个bug,原因是判断不及格时没有要求成绩大于零。于是修改MyUtil.java,增加对负分的判断,代码如下:
public class MyUtilTest { public static void main(String[] args) { //测试出错情况 if(MyUtil.percentage2fivegrade(-10) != "错误") System.out.println("test failed 1!"); else if(MyUtil.percentage2fivegrade(115) != "错误") System.out.println("test failed 2!"); else System.out.println("test passed!"); } }
我们还没有测试边界情况,输入为“0,60,70,80,90,100”这些边界情况进行测试的代码如下:
public class MyUtilTest { public static void main(String[] args) { //测试边界情况 if(MyUtil.percentage2fivegrade(0) != "不及格") System.out.println("test failed 1!"); else if(MyUtil.percentage2fivegrade(60) != "及格") System.out.println("test failed 2!"); else if(MyUtil.percentage2fivegrade(70) != "中等") System.out.println("test failed 3!"); else if(MyUtil.percentage2fivegrade(80) != "良好") System.out.println("test failed 4!"); else if(MyUtil.percentage2fivegrade(90) != "优秀") System.out.println("test failed 5!"); else if(MyUtil.percentage2fivegrade(100) != "优秀") System.out.println("test failed 6!"); else System.out.println("test passed!"); } }
测试结果如下:
我们发现边界情况中输入100时有一个Bug。我们修改MyUtil.java,把判断优秀的条件中包含输入为100的情况,代码如下:
public class MyUtil{ public static String percentage2fivegrade(int grade){ //如果成绩小于0,转成“错误” if ((grade < 0)) return "错误"; //如果成绩小于60,转成“不及格” else if (grade < 60) return "不及格"; //如果成绩在60与70之间,转成“及格” else if (grade < 70) return "及格"; //如果成绩在70与80之间,转成“中等” else if (grade < 80) return "中等"; //如果成绩在80与90之间,转成“良好” else if (grade < 90) return "良好"; //如果成绩在90与100之间,转成“优秀” else if (grade <= 100) return "优秀"; //如果成绩大于100,转成“错误” else return "错误"; } }
(2) TDD(Test Driven Devlopment, 测试驱动开发)
增加第一个测试用例testNormal
,注意测试用例前一定要有注解@Test
,测试用例方法名任意,输入以下代码:
import org.junit.Test; import junit.framework.TestCase; public class MyUtilTest extends TestCase { @Test public void testNormal() { assertEquals("不及格", MyUtil.percentage2fivegrade(55)); assertEquals("及格", MyUtil.percentage2fivegrade(65)); assertEquals("中等", MyUtil.percentage2fivegrade(75)); assertEquals("良好", MyUtil.percentage2fivegrade(85)); assertEquals("优秀", MyUtil.percentage2fivegrade(95)); } }
MyUtil
类还不存在,类中的percentage2fivegrade方法也不存在,我们在TDDDemo
的src
目录中新建一个MyUtil
的类,并实现percentage2fivegrade方法。
测试结果出现了一个红条(red bar),说明测试没通过,红条上面汇总了测试情况,运行了一个测试,没有错误,一个测试没通过。下面原因说的很清楚:测试代码第十行传入55时,期望结果是“不及格”,代码返回了“错误”,修改MyUtil.Java。
测试结果出现了一个绿条(green bar),说明测试通过了。TDD的目标是"Clean Code That Works",TDD的slogan是"Keep the bar green, to Keep the code clean"。
TDD的编码节奏是:
- 增加测试代码,JUnit出现红条
- 修改产品代码
- JUnit出现绿条,任务完成
(二)面向对象三要素
(1)抽象
抽象一词的本意是指人在认识思维活动中对事物表象因素的舍弃和对本质因素的抽取。抽象是人类认识复杂事物和现象时经常使用的思维工具,抽象思维能力在程序设计中非常重要,"去粗取精、化繁为简、由表及里、异中求同"的抽象能力很大程度上决定了程序员的程序设计能力。
抽象就是抽出事物的本质特征而暂时不考虑他们的细节。对于复杂系统问题人们借助分层次抽象的方法进行问题求解;在抽象的最高层,可以使用问题环境的语言,以概括的方式叙述问题的解。在抽象的较低层,则采用过程化的方式进行描述。在描述问题解时,使用面向问题和面向实现的术语。 程序设计中,抽象包括两个方面,一是过程抽象,二是数据抽象。
(2)封装、继承与多态
面向对象(Object-Oriented)的三要素包括:封装、继承、多态。面向对象的思想涉及到软件开发的各个方面,如面向对象分析(OOA)、面向对象设计(OOD)、面向对象编程实现(OOP)。OOA根据抽象关键的问题域来分解系统,关注是什么(what)。OOD是一种提供符号设计系统的面向对象的实现过程,用非常接近问题域术语的方法把系统构造成“现实世界”的对象,关注怎么做(how),通过模型来实现功能规范。OOP则在设计的基础上用编程语言(如Java)编码。贯穿OOA、OOD和OOP的主线正是抽象。 OOD中建模会用图形化的建模语言UML(Unified Modeling Language),UML是一种通用的建模语言,我们实验中使用umbrello进行建模,Windows中推荐大家使用 StarUML。
过程抽象的结果是函数,数据抽象的结果是抽象数据类型(Abstract Data Type,ADT),类可以作具有继承和多态机制的ADT。数据抽象才是OOP的核心和起源。
OO三要素的第一个要素是封装,封装就是将数据与相关行为包装在一起以实现信息就隐藏。Java中用类进行封装,比如一个Dog类:
public class Dog { private String color; public String getColor() { return color; } public void setColor(String color) { this.color = color; } public String bark(){ return "汪汪"; } public String toString(){ return "The Dog's color is " + this.getColor() +", and it shouts "+ this.bark() + "!"; } }
封装实际上使用方法将类的数据隐藏起来,控制用户对类的修改和访问数据的程度,从而带来模块化和信息隐藏的好处;接口是封装的准确描述手段。 Dog
类通过使用类和访问控制(private,public)隐藏了属性color
,开放了接口setColor()
,getColor()
,bark()
和toString
。Dog
类是一个模块,我们可以通过下面的代码使用它,测试代码与运行结果如下
我们可以用UML中的类图来描述类Dog
,首先我们在实验楼的环境中打开shell,在命令行中输入umbrello
,打开UML建模软件umbrello,先单击工具栏上的类图标,再在
class diagram(类图)
中单击一下,会弹出一个圣诞框,输入类名Dog
,
我们把鼠标放到
Dog
类上,单击右键,选择Properties
,在弹出的对话框中的Display
中去掉Public Only
选项,
我们把鼠标放到
Dog
类上,单击右键,选择New->Attribute
,在弹出的对话框中的填好Type
,Name
,并选好Visibility
,我们把鼠标放到Dog
类上,单击右键,选择New->Operation
,在弹出的对话框中的填好Type
,Name
,并选好Visibility
,
我们可以看到,在UML 里,一个类的属性能显示它的名字,类型,初始化值,属性也可以显示private,public,protected。 类的方法能显示它们的方法名,参数,返回类型,以及方法的private,public,protected属性。其中:
- +表示public
- #表示 protected
- -表示 private
使用UML可以让我们不必关注细节。同样,我们可以建立一个Cat
类(请大家模仿Dog类实现Cat类),
这时的测试类如以下UML图所示:
注意:UML类图要展示类之间的静态关系,AnimalTest
类依赖Dog
类和Cat
类,UML中依赖用带箭头的直线表示。 对应的测试代码和运行结果如下:
我们看到Dog
类和Cat
类都有Color
属性和相应的setter和getter方法,明显违反了前面提到的DRY
原则,我们可以通过继承解决这个问题,把Color
属性和相应的setter和getter方法放到父类Animal
中,如以下UML较图所示:
注意UML类图中继承的表示法,是用一个带三角的直线指向父类,通过继承,我们消除了Dog
类和Cat
类中的重复代码,符合DRY
的要求。 继承指一个类的定义可以基于另外一个已经存在的类,即子类基于父类,从而实现父类代码的重用。既存类称作基类、超类、父类(base class、super class、parent class),新类称作派生类、继承类、子类(derived class、inherited class、child class)。继承关系表达了”Is a kind of“的关系,称为“ISA”关系。继承的关键在于确认子类为父类的一个特殊类型 。继承是实现软件可重用的根基,是提高软件系统的可扩展性与可维护性的主要途径。 如上面所示,以封装为基础,继承可以实现代码复用,需要注意的是,继承更重要的作用是实现多态。 面向对象中允许不同类的对象对同一消息做出响应,即同一消息可以根据发送对象的不同而采用多种不同的行为方式,我们称此现象为多态性。Java中,多态是指不同的类对象调用同一个签名的成员方法时将执行不同代码的现象。多态是面向对象程序设计的灵活性和可扩展性的基础。 我们再看看上一个类图,我们可以进一步抽象,把Dog
类中的bark()
和Cat
类中的meow()
抽象成一个抽象方法shout()
,Dog
类和Cat
类中覆盖这个方法,如以下UML图所示: 大家注意UML类图中的Animal
类中的shout()
方法是抽象方法,是斜体的,Animal
类是抽象类,也是斜体的。
对应的代码如下:
public abstract class Animal { private String color; public String getColor() { return color; } public void setColor(String color) { this.color = color; } public abstract String shout(); } public class Dog extends Animal{ public String shout(){ return "汪汪"; } public String toString(){ return "The Dog's color is " + this.getColor() +", and it shouts "+ this.shout() + "!"; } } public class Cat extends Animal{ public String shout(){ return "喵喵"; } public String toString(){ return "The Cat's color is " + this.getColor() +", and it shouts "+ this.shout() + "!"; } }
大家注意,这时getInfo只需要一个了,参数为父类Animal
,当方法参数类型为父类时,可以传入子类的对象,如上面第8行所示。大家需要理解并记住“在Java中,当我们用父类声明引用,用子类生成对象时,多态就出现了”,如上面第6行所示。
另外,在Umbrello
中UML图是可以转化成Java代码的,有Java代码也可以生成UML图的。
(三)设计模式初步
(1)S.O.L.I.D原则
面向对象三要素是“封装、继承、多态”,任何面向对象编程语言都会在语法上支持这三要素。如何借助抽象思维用好三要素特别是多态还是非常困难的,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,依赖倒置原则)
(2)模式与设计模式
模式是某外在环境(Context) 下﹐对特定问题(Problem)的惯用解决之道(Solution)。模式必须使得问题明晰,阐明为什么用它来求解问题,以及在什么情况下有用,什么情况下不能起作用,每个模式因其重复性从而可被复用,本身有自己的名字,有可传授性,能移植到不同情景下。模式可以看作对一个问题可复用的专家级解决方法。 计算机科学中有很多模式:
- GRASP模式
- 分析模式
- 软件体系结构模式
- 设计模式:创建型,结构型,行为型
- 管理模式: The Manager Pool 实现模式
- 界面设计交互模式
- …
这里面最重要的是设计模式,在面向对象中设计模式的地位可以和面向过程编程中的数据结构的地位相当。
(3)设计模式实示例
设计模式提供一个用于细化软件系统的子系统或组件,或它们之间的关系图,它描述通信组件的公共再现结构,通信组件可以解决特定语境中的一个设计问题。
我们通过例子来学习一个设计模式(抽象工厂模式),并了解设计模式可能会存在的过度设计问题以及如何避免它。 我们设计了一个文档系统,如下图UML类图所示:
对应的代码如下:
客户如果要求系统支持Float
类,这是一个合理的要求,要支持Float
类,Document
类要修改两个地方,这违反了OCP
原则,使用多态可以解决部分问题:
对应的代码如下:
要支持Float
类,Document
类要修改构造方法,这还违反了OCP
原则。封装、继承、多态解决不了问题了,这时需要设计模式了:
抽象工厂模式应用如下:
对应代码如下:
我们看到通过增加了一层抽象层使代码符合了OCP原则。代码有良好的可扩充性、可维护性,代价是代码多了,效率变低下了。 设计模式初学者容易过度使用它们,导致过度设计,也就是说,遵守DRY和OCP当然好,但会出现YAGNI(You aren't gonna need it, 你不会需要它)问题。 DRY原则和YAGNI原则并非完全兼容。前者追求"抽象化",要求找到通用的解决方法;后者追求"快和省",意味着不要把精力放在抽象化上面,因为很可能"你不会需要它"。怎么平衡呢?有一个Rule of three (三次原则):第一次用到某个功能时,你写一个特定的解决方法;第二次又用到的时候,你拷贝上一次的代码(违反了DRY);第三次出现的时候,你才着手"抽象化",写出通用的解决方法。
当然,这些原则并不是孤立存在的,而是紧密联系的,遵循一个原则的同时也就遵循了另外一个或多个原则;反之,违反了其中一个原则也很可能同时就违反了另外一个或多个原则。 设计模式是这些原则在一些特定场景的应用结果。因此,可以把设计模式看作"框架",把OOD原则看作"规范"。 在学习设计模式的过程中,要经常性的反思,这个设计模式体现了面向对象设计原则中的哪个或哪一些原则。
(四)练习
1使用TDD的方式设计关实现复数类Complex。
伪代码:
设计一个复数类complex,分别将复数的实部和虚部作为属性,定义三个构造方法:
1.没有参数时默认为实部和虚部都为0;
2.一个参数时默认为实数,即虚部为0,
3.两个参数时分别为实部和虚部
再定义两个成员方法计算两个复数的和与差,然后用一个print()方法输出复数的值,当虚部为0时不输出虚部。
输出这两个复数的和与差。
产品代码:
测试代码
(五)、实验报告中统计自己的PSP(Personal Software Process)时间
步骤 |
耗时 |
百分比 |
需求分析 |
1h |
14.2% |
设计 |
1.5h | 21.4% |
代码实现 |
2h | 28.6% |
测试 |
1.5h | 21.4% |
分析总结 |
1h | 14.2% |