北京电子科技学院（BESTI）
实 验 报 告
课程：Java程序设计 班级：1353 姓名：陈巧然 学号：20135310
成绩： 指导教师：娄佳鹏 实验日期：2015.5.6
实验密级： 预习程度： 实验时间：22:30-3:30
仪器组次：10 必修/选修： 实验序号：2
实验名称： Java面向对象程序设计
实验目的与要求：1. 初步掌握单元测试和TDD
2. 理解并掌握面向对象三要素：封装、继承、多态
3. 初步掌握UML建模
4. 熟悉S.O.L.I.D原则
5. 了解设计模式
实验仪器：
|
名称 |
型号 |
数量 |
|
PC |
MacBook(win7) |
1 |
|
虚拟Linux系统 |
实验楼虚拟机 |
1 |
一、实验步骤
（一）单元测试
（1）三种代码：伪代码、产品代码、测试代码
举例说明：需求：要在一个MyUtil类中解决一个百分制成绩转成“优、良、中、及格、不及格”五级制成绩的功能。
a.伪代码
百分制转五分制：
如果成绩小于60，转成“不及格”
如果成绩在60与70之间，转成“及格”
如果成绩在70与80之间，转成“中等”
如果成绩在80与90之间，转成“良好”
如果成绩在90与100之间，转成“优秀”
其他，转成“错误
b.产品代码
c.测试代码
运行显示成功，说明产品代码此处没有错误
测试一般情况：
运行显示成功，一般情况下产品代码没有问题
测试异常情况：
运行显示出现错误，由此在产品代码中增加对负分的判断，再运行显示成功
测试边界值：
运行显示未考虑得分100的情况，修改产品代码：
自此代码完成
（2）TDD(Test Driven Devlopment, 测试驱动开发)：先写测试代码、再写产品代码的开发方法
一般步骤：
- 明确当前要完成的功能，记录成一个测试列表
- 快速完成编写针对此功能的测试用例
- 测试代码编译不通过（没产品代码呢）
- 编写产品代码
- 测试通过
- 对代码进行重构，并保证测试通过（重构下次实验练习）
- 循环完成所有功能的开发
用TDD的方式重新编写百分制转五分制的例子，感受有测试代码的好处
a.在Eclipse中单击【File->New->Java Project】新建一个TDDDemo的Java项目
b.在项目名TDDDemo上右键，在弹出的菜单中选定【New->Source Folder】新建一个测试目录test
c.在test目录上右键，在弹出的菜单中选定【New->JUnit Test Case】新建一个测试用例类MyUtilTest
d.在测试用例类MyUtilTest中，输入测试代码，如下图
e.红叉说明代码存在语法错误，因为MyUtil类还未建立，类中的percentage2fivegrade方法也不存在；
在TDDDemo的src目录中新建一个MyUtil的类，创建percentage2fivegrade方法，则测试代码没有语法错误了；
在MyUtilTest.java上右键，选择【Run as->JUnit Test】，效果如图
f.测试结果出现了红条（red bar）,说明测试没通过；
修改产品代码MyUtil.Java如下图，再如上一步运行测试代码，显示绿条
**TDD的编码节奏是：
- 增加测试代码，JUnit出现红条
- 修改产品代码
- JUnit出现绿条，任务完成
g.增加测试异常情况的用例testException和测试边界情况的用例testBoundary，运行测试代码出现红条；
修改产品代码，再运行测试代码出现绿条
（二）面向对象三要素
1、抽象
（1）对事物表象因素的舍弃和对本质因素的抽取
（2）“去粗取精、化繁为简、由表及里、异中求同”的抽象能力决定程序员的程序设计能力
（3）抽出事物的本质特征而暂时不考虑他们的细节
（4）抽象包括过程抽象和数据抽象
2、封装、继承与多态
（1）面向对象的三要素：封装、继承、多态。
（2）面向对象的思想涉及到软件开发的各个方面，如面向对象分析（OOA）、面向对象设计（OOD）、面向对象编程实现(OOP)。OOA根据抽象关键的问题域来分解系统，关注是什么（what）。贯穿OOA、OOD和OOP的主线正是抽象。
（3）OOD中建模会用图形化的建模语言UML（Unified Modeling Language）,UML是一种通用的建模语言，实验中使用umbrello进行建模
（4）过程抽象的结果是函数，数据抽象的结果是抽象数据类型，数据抽象是OOP的核心和起源
（5）封装实际上使用方法将类的数据隐藏起来，控制用户对类的修改和访问数据的程度,从而带来模块化和信息隐藏的好处；接口是封装的准确描述手段。
举例说明：
a.Java中用类进行封装，比如一个Dog类:
b.Dog类通过使用类和访问控制隐藏了属性color,开放了接口setColor(),getColor(),bark()和toString。Dog类是一个模块，我们可以通过下面的代码使用它，测试代码与运行结果如下
c.可以用UML中的类图来描述类Dog:打开shell，在命令行中输入umbrello，打开UML建模软件umbrello;
单击工具栏上的类图标，再在class diagram(类图)中单击一下，会弹出一个框，输入类名Dog；
把鼠标放到Dog类上，单击右键，选择Properties,在弹出的对话框中的Display中去掉Public Only选项；
把鼠标放到Dog类上，单击右键，选择New->Attribute,在弹出的对话框中的填好Type,Name,并选好Visibility，得到如下图Dog类
*在UML 里，一个类的属性能显示它的名字，类型，初始化值，属性也可以显示private，public，protected。 类的方法能显示它们的方法名，参数，返回类型，以及方法的private，public，protected属性。其中：+表示public；#表示 protected；-表示 private. 使用UML可以让我们不必关注细节
d.仿照Dog类创建Cat类和AnimalTest类
e.UML类图要展示类之间的静态关系，AnimalTest类依赖Dog类和Cat类，UML中依赖用带箭头的直线表示
对应代码：
f.Dog类和Cat类都有Color属性和相应的set和get方法，违反了前面提到的DRY原则，我们可以通过继承解决这个问题，把Color属性和相应方法放到父类Animal中，如以下UML较图所示：
（注意UML类图中继承的表示法，是用一个带三角的直线指向父类）
g.进一步抽象，把Dog类中的bark()和Cat类中的meow()抽象成一个抽象方法shout(),Dog类和Cat类中覆盖这个方法，如以下UML图所示：
（注意UML类图中的Animal类中的shout()方法是抽象方法，是斜体的，Animal类是抽象类，也是斜体的）
对应代码：
（三）设计模式初步
1、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,依赖倒置原则)
（1）OCP是最重要的一个原则，其内容为：
- software entities (class, modules, function, etc.) should open for extension,but closed for modification.
- 软件实体（类，模块，函数等）应该对扩充开放，对修改封闭。
基于OCP，利用面向对象中的多态性（Polymorphic），更灵活地处理变更拥抱变化，OCP可以用抽象和继承、面向接口编程手段实现
（2）SRP的内容是：
- There should never be more than one reason for a class to change
- 决不要有一个以上的理由修改一个类
（3）LSP的内容是：
- Subtypes must be substitutable for their base types
- Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it
- 子类必须可以被其基类所代
- 使用指向基类的指针或引用的函数，必须能够在不知道具体派生类对象类型的情况下使用它
（4）ISP的内容是：
- Clients should not be forced to depend upon interfaces that they do not use
- 客户不应该依赖他们并未使用的接口
（5）DIP的内容是：
- High level modules should not depend upon low level modules. Both should depend upon abstractions
- Abstractions should not depend upon details. Details should depend upon abstractions
- 高层模块不应该依赖于低层模块。二者都应该依赖于抽象
- 抽象不应该依赖于细节。细节应该依赖于抽象
2、模式与设计模式
模式是某外在环境(Context) 下﹐对特定问题(Problem)的惯用解决之道(Solution)。模式必须使得问题明晰，阐明为什么用它来求解问题，以及在什么情况下有用，什么情况下不能起作用。每个模式因其重复性从而可被复用，本身有自己的名字，有可传授性，能移植到不同情景下。模式可以看作对一个问题可复用的专家级解决方法。
计算机科学中有很多模式:
• GRASP模式
• 分析模式
• 软件体系结构模式
• 设计模式：创建型，结构型，行为型
• 管理模式： The Manager Pool 实现模式
• 界面设计交互模式
• …
其中最重要的是设计模式
3、设计模式实示例
（1）设计模式(design pattern)提供一个用于细化软件系统的子系统或组件，或它们之间的关系图，它描述通信组件的公共再现结构，通信组件可以解决特定语境中的一个设计问题。设计模式背后是抽象和SOLID原则。
设计模式有四个基本要素：
• Pattern name：描述模式，便于交流，存档
• Problem：描述何处应用该模式
• Solution：描述一个设计的组成元素，不针对特例
• Consequence：应用该模式的结果和权衡（trade-offs）
（2）学习设计模式是为了了解设计模式可能会存在的过度设计问题以及如何避免它。
（3）除SOLID原则外还有很多其它的面向对象原则。如：
- "组合替代继承":这是说相对于继承，要更倾向于使用组合；
- "笛米特法则"：这是说"你的类对其它类知道的越少越好"；
- "共同封闭原则"：这是说"相关类应该打包在一起"；
- "稳定抽象原则"：这是说"类越稳定，越应该由抽象类组成";
这些原则并不是孤立存在的，而是紧密联系的，遵循一个原则的同时也就遵循了另外一个或多个原则；反之，违反了其中一个原则也很可能同时就违反了另外一个或多个原则。 设计模式是这些原则在一些特定场景的应用结果。因此，可以把设计模式看作"框架"，把OOD原则看作"规范"。 在学习设计模式的过程中，要经常性的反思，这个设计模式体现了面向对象设计原则中的哪个或哪一些原则。
（四）练习
1.使用TDD的方式设计关实现复数类Complex
（1）伪代码：
复数类Complex
复数的值=a+bi;
加=(a1+a2)+(b1+b2)i;
减=(a1-a2)+(b1-b2)i;
（2）产品代码：
（3）测试代码：
2.PSP时间统计
|
步骤 |
耗时 |
百分比 |
|
需求分析 |
20 |
18% |
|
设计 |
10 |
9% |
|
代码实现 |
40 |
37% |
|
测试 |
30 |
27% |
|
分析总结 |
10 |
9% |
3.总结单元测试的好处
（1）分析需求后先写伪代码，确定思路，再写产品代码和测试代码，避免直接打开编辑器编代码会出现思路混乱
（2）测试代码和产品代码分开，可以放心用测试代码调试而暂时不影响产品代码的使用
（3）用TDD方式先写出测试代码，可以避免产品代码中的很多错误，容易直接写出正确代码
（4）测试代码对产品代码有指导作用，可作为使用说明一并给使用者，同时也方便使用者自行修改
二、总结
（一）遇到的问题和解决方法
1.老师给的虚拟机未安装成功，还是用实验楼网页里的虚拟机，一如既往地慢和卡，耗费太多时间
2.实验步骤没有上次实验给的详细，个别细节处不知道如何操作，各种尝试才得到相同效果
3.感觉实验内容有点多，做了好多次都只做了一点点，退出虚拟机后所有痕迹又都清除了，导致前面部分重复做了三四次，很无奈
4.本来不知道复数类的含义，百度了具体要求又参考了群里老师给的提示才有了大概思路
（二）收获和感想
1.接触了虚拟机中的umbrello，知道了创建UML图的基本步骤，UML可以简化类的表示，不用看冗长乏味的代码就可以知道类的属性以及类之间的静态关系
2.之前跟着毕老师的视频学习大致了解了java中抽象的思想，以及封装、继承、多态三个要素，而本次实验中老师对这些概念内容给了系统的总结和讲解，让我对java的核心内容有了更准确深刻的理解
3.经过上次的体验，这次有了会耗费很久的心理准备，但仍然被折磨到了……