实验二 Java面向对象程序设计
实验内容
1. 初步掌握单元测试和TDD
2. 理解并掌握面向对象三要素：封装、继承、多态
3. 初步掌握UML建模
4. 熟悉S.O.L.I.D原则
5. 了解设计模式
实验要求
1.没有Linux基础的同学建议先学习《Linux基础入门（新版）》《Vim编辑器》 课程
2.完成实验、撰写实验报告，实验报告以博客方式发表在博客园，注意实验报告重点是运行结果，遇到的问题(工具查找，安装，使用，程序的编辑，调试，运行等)、解决办法（空洞的方法如“查网络”、“问同学”、“看书”等一律得0分）以及分析（从中可以得到什么启示，有什么收获，教训等）。报告可以参考范飞龙老师的指导
3. 严禁抄袭，有该行为者实验成绩归零，并附加其他惩罚措施。
4. 请大家先在实验楼中的~/Code目录中用自己的学号建立一个目录，代码和UML图要放到这个目录中，截图中没有学号的会要求重做，然后跟着下面的步骤练习。
实验步骤
（一）单元测试
(1) 三种代码
编程是智力活动，不是打字，编程前要把干什么、如何干想清楚才能把程序写对、写好。与目前不少同学一说编程就打开编辑器写代码不同，我希望同学们养成一个习惯，当你们想用程序解决问题时，要会写三种码：
- 伪代码
- 产品代码
- 测试代码
我们通过一个例子说明如何写这三种代码。
需求：我们要在一个
MyUtil类中解决一个百分制成绩转成“优、良、中、及格、不及格”五级制成绩的功能。
我们先写伪代码，伪代码可以用汉语写，推荐大家用英语写，伪代码与具体编程语言无关，不要写与具体编程语言语法相关的语句（如用malloc分配内存，这样只能用C语言编程了），伪代码从意图层面来解决问题，最终，伪代码是产品代码最自然的、最好的注释。针对上面的问题，我们可以通过伪代码这样解决：
百分制转五分制：
如果成绩小于60，转成“不及格”
如果成绩在60与70之间，转成“及格”
如果成绩在70与80之间，转成“中等”
如果成绩在80与90之间，转成“良好”
如果成绩在90与100之间，转成“优秀”
其他，转成“错误”
简单吧？想用编程来解决问题，首先要用伪代码表明自己想明白了。
有了伪代码，我们用特定编程语言翻译一下，就是可用的产品代码了，当然，我们在这要选用Java，小菜一碟了，翻译好的MyUtil.java如下：
public class MyUtil{
public static String percentage2fivegrade(int grade){
//如果成绩小于60，转成“不及格”
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 "优秀";
//其他，转成“错误”
else
return "错误";
}
}
产品代码写完了，如果别人要使用这个代码，把MyUtil.java拷给他就可以了。但是作为负责任的你，肯定会担心自己的程序会有Bug。如果别人用自己的代码发现一堆Bugs，那多没面子！怎么办？写了产品代码,我们还要写测试代码，证明自己的代码没有问题。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!");
}
}
在Eclipse中运行结果如下，测试结果符合预期：
我们不能只测试正常情况，下面看看异常情况如何，比如输入为负分或大于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 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 "错误";
}
}
再次运行测试，测试结果符合预期，如下图所示：
测试够了吗？还不够，一般代码在边界处最容易出错，我们还没有测试边界情况，我们对输入为“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 "错误";
}
}
这时测试都符合预期了，我们把MyUtil.java提供给别人使用时，心里比较有底气了。那如何保证单元测度是充分的呢？我们的一般要求是测试代码要比产品代码多。如何写测试，《单元测试之道》提出了Right-BICEP的方法，大家可以参考一下。
软件是由多人合作完成的，不同人员的工作相互有依赖关系。软件的很多错误都来源于程序员对模块功能的误解、疏忽或不了解模块的变化。如何能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？单元测试就是一个很有效的解决方案。
(2) TDD(Test Driven Devlopment, 测试驱动开发)
前面的例子，我们先写产品代码，然后再写测试代码，通过测试发现了一些Bugs，提高了代码质量。这有问题吗？软件开发从建筑中吸取了很多营养，我们看看一个砌墙的例子，如下图：
工人是“先把墙砌好的，再用绳子测一下墙平不平，直不直，如果不平或不直拆了重砌”，还是“先用绳子给出平和直的标准，然后靠着绳子砌墙，从而保证了墙砌出来就是又平又直的”呢？答案是不言而喻的了。
拿编程做对比，我们是该“先写产品代码，然后再写测试代码，通过测试发现了一些Bugs，修改代码”，还是该“先写测试代码，然后再写产品代码，从而写出来的代码就是正确的”呢？当然先写测试代码了。这种先写测试代码，然后再写产品代码的开发方法叫“测试驱动开发”（TDD）。TDD的一般步骤如下：
- 明确当前要完成的功能，记录成一个测试列表
- 快速完成编写针对此功能的测试用例
- 测试代码编译不通过（没产品代码呢）
- 编写产品代码
- 测试通过
- 对代码进行重构，并保证测试通过（重构下次实验练习）
- 循环完成所有功能的开发
基于TDD，我们不会出现过度设计的情况，需求通过测试用例表达出来了，我们的产品代码只要让测试通过就可以了。
Java中有单元测试工具JUnit来辅助进行TDD，我们用TDD的方式把前面百分制转五分制的例子重写一次，体会一下有测试工具支持的开发的好处。
打开Eclipse,单击File->New->Java Project新建一个TDDDemo的Java项目，如下图：
我们在TDDDemo项目中，把鼠标放到项目名TDDDemo上，单击右键，在弹出的菜单中选定New->Source Folder新建一个测试目录test，如下图：
我们把鼠标放到test目录上，单击右键，在弹出的菜单中选定New->JUnit Test Case新建一个测试用例类MyUtilTest，如下图：
我们增加第一个测试用例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));
}
}
输入完毕，Eclipse中如下图所示：
图中的红叉说明代码存在语法错误，原因很简单，MyUtil类还不存在，类中的percentage2fivegrade方法也不存在，我们在TDDDemo的src目录中新建一个MyUtil的类，并实现percentage2fivegrade方法，如下图所示：
大家可以看到现在测试代码没有语法错误了，我们把鼠标放到MyUtilTest.java上，单击右键，选择Run as->JUnit Test,如下图：
测试结果出现了一个红条（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出现绿条，任务完成
我们增加一个测试异常情况的用例testException,如下图：
我们增加一个测试边界情况的用例testBoundary,如下图：
如何让JUnit的gree bar出来，动手实验一下，如下图：
不管用不用TDD，写出高质量的测试用例才是最重要的，如何进行单元测试，大家可参考一下《单元测试之道》这本书。另外，《Agile Java 中文版》展示了如何将Java和TDD进行有效的整合，通过TDD驱动项目开发，有兴趣的可以参考。
（二）面向对象三要素
（1）抽象
抽象一词的本意是指人在认识思维活动中对事物表象因素的舍弃和对本质因素的抽取。抽象是人类认识复杂事物和现象时经常使用的思维工具，抽象思维能力在程序设计中非常重要，"去粗取精、化繁为简、由表及里、异中求同"的抽象能力很大程度上决定了程序员的程序设计能力。
抽象就是抽出事物的本质特征而暂时不考虑他们的细节。对于复杂系统问题人们借助分层次抽象的方法进行问题求解；在抽象的最高层，可以使用问题环境的语言，以概括的方式叙述问题的解。在抽象的较低层，则采用过程化的方式进行描述。在描述问题解时，使用面向问题和面向实现的术语。
程序设计中，抽象包括两个方面，一是过程抽象，二是数据抽象。
我们举个例子说明一下。比如有了以下Java代码：
System.out.println(1);
System.out.println(2);
System.out.println(3);
可以打印出“1,2,3”，想打引“1,2,3,4”怎么办？同学们的做法大多是把上面的代码拷贝下来，再加一行：
System.out.println(1);
System.out.println(2);
System.out.println(3);
System.out.println(4);
这就是没有学会过程抽象的做法“拷贝粘贴”式开发。解决问题没？解决了，但有问题，比如想打印出“1..100"怎么办？粘贴100行？这两段代码有三行重复的代码，违反了常见的一个编程原则DRY(Don't Repeat Yourself)，解决的方法是进行过程抽象，写一个函数printn：
public void printn(int n){
for(int i=1; i<=n; i++)
System.out.println(n);
}
上面两段代码就可以用;
printn(3);
printn(4);
代替了，打印出“1..100"也很简单，只要调用printn(100);就行了。
（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() + "!";
}
}
封装实际上使用方法(method)将类的数据隐藏起来，控制用户对类的修改和访问数据的程度,从而带来模块化(Modularity)和信息隐藏(Information hiding)的好处；接口（interface）是封装的准确描述手段。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图的，大家摸索一下吧。学习UML，《UML精粹》是本不错的入门书，学会了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,依赖倒置原则)
OCP是OOD中最重要的一个原则，OCP的内容是：
- software entities (class, modules, function, etc.) should open for extension,but closed for modification.
- 软件实体（类，模块，函数等）应该对扩充开放，对修改封闭。
对扩充开放（Open For Extension ）要求软件模块的行为必须是可以扩充的，在应用需求改变或需要满足新的应用需求时，我们要让模块以不同的方式工作； 对修改封闭（Closed for Modification ）要求模块的源代码是不可改动的，任何人都不许修改已有模块的源代码。 基于OCP，利用面向对象中的多态性（Polymorphic），更灵活地处理变更拥抱变化，OCP可以用以下手段实现：（1）抽象和继承，（2）面向接口编程。
比如，在一个图形系统中，已经存在三个模块Shape,Square,Circle,如下图所示：
用户现大需要一个Triangle模块是一个合理的要求，由于我们使用了多态，原先的模块不需要改变，只要新增加一个模块Triangle就可以了，如下图所示：
这个图形系统是符合OCP原则的。
SRP的内容是：
- There should never be more than one reason for a class to change
- 决不要有一个以上的理由修改一个类
对象提供单一职责的高度封装，对象的改变仅仅依赖于单一职责的改变，它基于软件设计中的高内聚性定义。如何判断一个类是不是符合SRP原则，我们看一个例子。下面这个类符合SRP原则吗？
好象所有的方法都是汽车类（Automobile）需要的，我们可以通过以下方法对一个类做SRP分析：用类做主语，用方法名做谓语，看看逻辑上能不能说的通，如下图所示：
分析的结果，Automabile类应该分成四个类，如下图所示：
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
- 子类必须可以被其基类所代
- 使用指向基类的指针或引用的函数，必须能够在不知道具体派生类对象类型的情况下使用它
LSP是Liskov女士提出的：LSP的核心思想是父类型对象可以被子类型对象所取代。我们前面举的Animal,Dog,Cat的那个例子是符合LSP原则的。下面是一个常见的反例，不少Java教材讲继承时都举这个例子，其实是错误的。
请大家想一想，Square类为何不能继承Rectangle类，在数学上好像是没有什么问题的呀。LSP告诉大家的一点是不要滥用继承，LSP原则清楚地指出，OOD中“ISA关系”是就行为功能而言。行为功能（behavior）不是内在的、私有的，而是外在、公开的，是客户程序所依赖的接口。
ISP的内容是：
- Clients should not be forced to depend upon interfaces that they do not use
- 客户不应该依赖他们并未使用的接口
首先要理解客户是什么，前面讲到一个XXXX类，要有一个配套的XXXXTest类，XXXXTest中要使用XXXX类，XXXXTest类就可以看作XXXX类的客户。我们看一个例子：
接口RowSetManager的功能过多，我们应该把这个接口分成多个接口，以便利于复用：
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
- 高层模块不应该依赖于低层模块。二者都应该依赖于抽象
- 抽象不应该依赖于细节。细节应该依赖于抽象
通过接口或者抽象类，DIP在应用中通过依赖注入的方式实现解耦，重用低级模块，重用实现，解除依赖。
我们看一个例子：设想一个简单的程序，其任务就是实现将键盘输入的字符拷贝到打印机上。进一步假设实现平台中的操作系统并不支持设备无关性。我们可以这样实现：
这样，上层函数copy依赖下层函数read,write。DIP改变了依赖的方向，要求下面依赖上面，我们使用抽象类实现DIP，如下图所示：
（2）模式与设计模式
模式是某外在环境(Context) 下﹐对特定问题(Problem)的惯用解决之道(Solution)。模式必须使得问题明晰，阐明为什么用它来求解问题，以及在什么情况下有用，什么情况下不能起作用，每个模式因其重复性从而可被复用，本身有自己的名字，有可传授性，能移植到不同情景下。模式可以看作对一个问题可复用的专家级解决方法。
计算机科学中有很多模式:
- GRASP模式
- 分析模式
- 软件体系结构模式
- 设计模式：创建型，结构型，行为型
- 管理模式： The Manager Pool 实现模式
- 界面设计交互模式
- …
这里面最重要的是设计模式，在面向对象中设计模式的地位可以和面向过程编程中的数据结构的地位相当。
（3）设计模式实示例
设计模式(design pattern)提供一个用于细化软件系统的子系统或组件，或它们之间的关系图，它描述通信组件的公共再现结构，通信组件可以解决特定语境中的一个设计问题。
如图，随着系统中对象的数量增多，对象之间的交互成指数增长，设计模式可以帮我们以最好的方式来设计系统。设计模式背后是抽象和SOLID原则。
设计模式有四个基本要素：
- Pattern name：描述模式，便于交流，存档
- Problem：描述何处应用该模式
- Solution：描述一个设计的组成元素，不针对特例
- Consequence：应用该模式的结果和权衡（trade-offs）
我们先要学习的是GOF的23个设计模式：
Java类库中大量使用设计模式：
- Factory：java.util.Calendar
- Compsite：java.awt.Container
- Decorator：java I/0
- Iterator：java.util.Enumeration
- Strategy：java.awt.LayoutManager
- …
我们通过例子来学习一个设计模式（抽象工厂模式），并了解设计模式可能会存在的过度设计问题以及如何避免它。
我们设计了一个文档系统，如下图UML类图所示：
对应的代码如下：
class Integer {
int value;
public Integer(){
value=100;
}
public void DisplayValue(){
System.out.println(value);
}
}
class Document {
Integer pi;
public Document(){
pi = new Integer();
}
public void DisplayData(){
pi.DisplayValue();
}
}
public class MyDoc{
static Document d;
public static void main(String [] args) {
d = new Document();
d.DisplayData();
}
}
客户如果要求系统支持Float类，这是一个合理的要求，要支持Float类，Document类要修改两个地方，这违反了OCP原则，使用多态可以解决部分问题：
对应的代码如下：
abstract class Data{
public abstract void DisplayValue();
}
class Integer extends Data {
int value;
Integer(){
value=100;
}
public void DisplayValue(){
System.out.println(value);
}
}
class Document {
Data pd;
Document() {
pd=new Integer();
}
public void DisplayData(){
pd.DisplayValue();
}
}
public class MyDoc {
static Document d;
public static void main(String[] args) {
d = new Document();
d.DisplayData();
}
}
要支持Float类，Document类要修改构造方法，这还违反了OCP原则。封装、继承、多态解决不了问题了，这时需要设计模式了：
抽象工厂模式应用如下：
对应代码如下：
// Server Classes
abstract class Data {
abstract public void DisplayValue();
}
class Integer extends Data {
int value;
Integer() {
value=100;
}
public void DisplayValue(){
System.out.println (value);
}
}
// Pattern Classes
abstract class Factory {
abstract public Data CreateDataObject();
}
class IntFactory extends Factory {
public Data CreateDataObject(){
return new Integer();
}
}
//Client classes
class Document {
Data pd;
Document(Factory pf){
pd = pf.CreateDataObject();
}
public void DisplayData(){
pd.DisplayValue();
}
}
//Test class
public class MyDoc {
static Document d;
public static void main(String[] args) {
d = new Document(new IntFactory());
d.DisplayData();
}
}
我们看到通过增加了一层抽象层使代码符合了OCP原则。代码有良好的可扩充性、可维护性，代价是代码多了，效率变低下了。
设计模式初学者容易过度使用它们，导致过度设计，也就是说，遵守DRY和OCP当然好，但会出现YAGNI(You aren't gonna need it, 你不会需要它)问题。
DRY原则和YAGNI原则并非完全兼容。前者追求"抽象化"，要求找到通用的解决方法；后者追求"快和省"，意味着不要把精力放在抽象化上面，因为很可能"你不会需要它"。怎么平衡呢？有一个Rule of three （三次原则）：第一次用到某个功能时，你写一个特定的解决方法；第二次又用到的时候，你拷贝上一次的代码（违反了DRY）；第三次出现的时候，你才着手"抽象化"，写出通用的解决方法。
设计模式学习先参考一下《深入浅出设计模式》，这本书可读性非常好。
除SOLID原则外还有很多其它的面向对象原则。如：
- "组合替代继承":这是说相对于继承，要更倾向于使用组合；
- "笛米特法则"：这是说"你的类对其它类知道的越少越好"；
- "共同封闭原则"：这是说"相关类应该打包在一起"；
- "稳定抽象原则"：这是说"类越稳定，越应该由抽象类组成";
当然，这些原则并不是孤立存在的，而是紧密联系的，遵循一个原则的同时也就遵循了另外一个或多个原则；反之，违反了其中一个原则也很可能同时就违反了另外一个或多个原则。 设计模式是这些原则在一些特定场景的应用结果。因此，可以把设计模式看作"框架"，把OOD原则看作"规范"。 在学习设计模式的过程中，要经常性的反思，这个设计模式体现了面向对象设计原则中的哪个或哪一些原则。
（四）练习
1使用TDD的方式设计关实现复数类Complex。
2.实验报告中统计自己的PSP(Personal Software Process)时间
| 步骤 | 耗时 | 百分比 |
|---|---|---|
| 需求分析 | ||
| 设计 | ||
| 代码实现 | ||
| 测试 | ||
| 分析总结 |
3. 实现要有伪代码，产品代码，测试代码。
4.总结单元测试的好处
参考资料
1.《UML精粹》
2.《构建之法 （电子版）》,著者邹欣Blog
3.《深入浅出设计模式》
4.《解析极限编程》
5.《单元测试之道》
6.《代码大全》
7.《代码的抽象三原则》
工具
欢迎关注“rocedu”微信公众号(手机上长按二维码)
做中教，做中学，实践*同进步！
版权声明：*转载-非商用-非衍生-保持署名| Creative Commons BY-NC-ND 3.0