JUnit设计模式分析
JUnit是一个优秀的Java单元测试框架，由两位世界级软件大师Erich Gamma 和Kent Beck共同开发完成。本文将向读者介绍在开发JUnit的过程中是怎样应用设计模式的。
关键词：单元测试JUnit 设计模式
1 JUnit概述
1.1 JUnit概述
JUnit是一个开源的java测试框架，它是Xuint测试体系架构的一种实现。在JUnit单元测试框架的设计时，设定了三个总体目标，第一个是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；第二个是使测试单元保持持久性；第三个则是可以利用既有的测试来编写相关的测试。所以这些目的也为什么使用模式的根本原因。
1.2 JUnit开发者
JUnit最初由Erich Gamma 和Kent Beck所开发。Erich Gamma博士是瑞士苏伊士国际面向对象技术软件中心的技术主管，也是巨著《设计模式》的四作者之一。Kent Beck先生是XP（Extreme Programmin g）的创始人，他倡导软件开发的模式定义，CRC卡片在软件开发过程中的使用，HotDraw软件的体系结构，基于xUnit的测试框架，重新评估了在软件开发过程中测试优先的编程模式。是《The Smalltalk Best Practice Patterns》、《Extreme Programming Explained》和《Planning Extreme Programming（与Martin Fowler合著）》的作者。
由于JUnit是两位世界级大师的作品，所以值得大家细细品味，现在就把JUnit中使用的设计模式总结出来与大家分享。我按照问题的提出，模式的选择，具体实现，使用效果这种过程展示如何将模式应用于JUnit。
2 JUnit体系架构
JUnit的设计使用以Patterns Generate Architectures（请参见Patterns Generate Architectures, Kent Beck and Ralph Johnson, ECOOP 94）的方式来架构系统。其设计思想是通过从零开始来应用设计模式，然后一个接一个，直至你获得最终合适的系统架构。
3 JUnit设计模式
3.1 JUnit框架组成
l 对测试目标进行测试的方法与过程集合，可将其称为测试用例。（TestCase）
l 测试用例的集合，可容纳多个测试用例（TestCase），将其称作测试包。（TestSuite）
l 测试结果的描述与记录。（TestResult）
l 测试过程中的事件监听者（TestListener）
l 每一个测试方法所发生的与预期不一致状况的描述，称其测试失败元素。（TestFailure）
l JUnit Framework中的出错异常。（AssertionFailedError）
3.2 Command（命令）模式
3.2.1 问题
首先要明白，JUnit是一个测试framework，测试人员只需开发测试用例。然后把这些测试用例组成请求(有时可能是一个或者多个)，发送到JUnit FrameWork，然后由JUnit执行测试，最后报告详细测试结果。其中包括执行的时间，错误方法，错误位置等。这样测试用例的开发人员就不需知道JUnit内部的细节，只要符合它定义的请求格式即可。从JUnit的角度考虑，它并不需要知道请求TestCase的操作信息，仅把它当作一种命令来执行，然后把执行测试结果发给测试人员。这样就使JUnit 框架和TestCase的开发人员独立开来，使得请求的一方不必知道接收请求一方的详细信息，更不必知道是怎样被接收，以及怎样被执行的，实现系统的松耦合。
3.2.2 模式的选择
Command（命令）模式（请参见Gamma, E., et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1995）则能够比较好地满足需求。摘引其意图（intent），将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化；对请求进行排队或记录请求日
志https://www.doczj.com/doc/255716689.html,mand告诉我们可以为一个操作生成一个对象并给出它的一个execute（执行）方法。
3.2.3 实现
为了实现Command模式，首先定义了一个接口Test,其中Run便是Command的Execute方法。然后又使用Default Adapter模式为这个接口提供了缺省实现TestCase抽象类，这样我们开发人员就可以从这个缺省实现进行集成，而不必从Test接口进行实现。
我们首先来分析Test接口。它存在一个是countTestCases方法，它来统计这次测试有多少个TestCase，另外一个方法就是我们的Command模式的Excecute方法，这里命名为run。还有一个参数TestResult，它来统计测试结果
public interface Test {
/**
* Counts the number of test cases that will be run by this test.
*/
public abstract int countTestCases();
/**
* Runs a test and collects its result in a TestResult instance.
*/
public abstract void run(TestResult result);
}
TestCase是该接口的抽象实现，它增加了一个测试名称，因为每一个TestCase在创建时都要有一个名称，因此若一个测试失败了，你便可识别出是哪个测试失败。
public abstract class TestCase extends Assert implements Test {
/**
* the name of the test case
*/
private String fName;
public void run(TestResult result) {
result.run(this);
}
}
这样我们的开发人员，编写测试用例时，只需继承TestCase，来完成run方法即可，然后JUnit获得测试用例，执行它的run方法，把测试结果记录在TestResult之中，目前可以暂且这样理解。
3.2.4 效果
下面来考虑经过使用Command模式后给系统的架构带来了那些效果：
l Command模式将实现请求的一方（TestCase开发）和调用一方（JUnit Fromwork）进行解藕
l Command模式使新的TestCase很容易的加入，无需改变已有的类，只需继承TestCase类即可，这样方便了测试人员
l Command模式可以将多个TestCase进行组合成一个复合命令，实际你将看到TestSuit就是它的复合命令，当然它使用了Composite模式
l Command模式容易把请求的TestCase组合成请求队列，这样使接收请求的一方（Junit Fromwork）,容易的决定是否执行请求，或者一旦发现测试用例失败或者错误可以立刻停止进行报告
l Command模式可以在需要的情况下，方便的实现对请求的Undo和Redo，以及记录Log,这部分目前在JUnit中还没有实现，将来是很容易加入的
3.3 Composite（组合）
3.3.1 问题
为了获得对系统状态的信心，需要运行多个测试用例。通过我们使用Command模式，JUnit能够方便的运行一个单独的测试案例之后产生测试结果。可是在实际的测试过程中，需要把多个测试用例进行组合成为一个复合的测试用例，当作一个请求发送给JUnit.这样JUnit就为面临一个问题，必须考虑测试请求的类型，是一个单一的TestCase还是一个复合的TestCase，甚至于要区分到底有多少个TestCase。这样Junit 框架就要完成像下面这样的代码：
if（isSingleTestCase(objectRequest)）{
//如果是单个的TestCase,执行run，获得测试结果
objectRequest.run()
}else if(isCompositeTestCase(objectRequest)){
//如果是一个复合TestCase,就要执行不同的操作，然后进行复杂的算法进行分
//解，之后再运行每一个TestCase，最后获得测试结果，同时又要考虑
//如果中间测试错误怎样？？？？、
…………………………
…………………………
}
这样JUnit必须考虑区分请求（TestCase）的类型（是单个testCase还是复合testCase），而实际上大多数情况下，测试人员认为这两者是一样的。对于这两者的区别使用，又会使程序变得更加复杂，难以维护和扩展。于是要考虑，怎样设计JUnit才可以实现不需要区分单个TestCase还是复合TestCase，把它们统一成相同的请求？
3.3.2 模式的选择
当测试调用者不必关心其运行的是一个或多个测试案例的请求时，能够轻松地解决这个问题模式就是Composite（组合）模式。摘引其意图，将对象组合成树形结构以表示部分-整体的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。在这里部分-整体的层次结构是解决问题的关键，可以把单个的TestCase看作部分，而把复合的TestCase(TestSuit)看作整体。这样我们使用该模式便可以恰到好处得解决这个难题。
Composite模式结构
Composite模式引入以下的参与者：
n Component：这是一个抽象角色，它给参加组合的对象规定一个接口。这个角色，给出共有的接口和默认得行为。其实就我们的Test接口，它定义出run方法。
n Composite：实现共有接口并维护一个测试的集合。就是我们的复合TestCase，TestSuit
n Leaf：代表参加组合的对象，它没有下级子对象，仅定义出参加组合的原始对象的行为，其实就是单一的测试用例TestCase,它仅实现Test接口的方法。
其实componsite模式根据所实现的接口区分为两种形式，分别称为安全式和透明式。JUnit中使用了安全式的结构，这样在TestCase中没有管理子对象的方法。
3.3.3 实现
composite模式告诉我们要引入一个Component抽象类，为Leaf对象和composite对象定义公共的接口。这个类的基本意图就是定义一个接口。在Java中使用Composite模式时，优先考虑使用接口，而非抽象类，因此引入一个Test接口。当然我们的leaf就是TestCase了。其源代码如下：
//composite模式中的Component角色
public interface Test {
public abstract void run(TestResult result);
}
//composite模式中的Leaf角色
public abstract class TestCase extends Assert implements Test {
public void run(TestResult result) {
result.run(this);
}
}
下面，列出Composite源码。将其取名为TestSuit类。TestSuit有一个属性fTests (Vector类型)中保存了其子测试用例（child test），提供addTest方法来实现增加子对象TestCase ,并且还提供testCount 和tests 等方法来操作子对象。最后通过run()方法实现对其子对象进行委托（delegate），最后还提供addTestSuite方法实现递归，构造成树形。
public class TestSuite implements Test {
private Vector fTests= new Vector(10);
public void addTest(Test test) {
fTests.addElement(test);
}
public int testCount() {
return fTests.size();
}
public Enumeration tests() {
return fTests.elements();
}
public void run(TestResult result) {
for (Enumeration e= tests(); e.hasMoreElements(); ) {
Test test= (Test)e.nextElement();
runTest(test, result);
}
}
public void addTestSuite(Class testClass) {
addTest(new TestSuite(testClass));
}
}
分析了Composite模式的实现后我们列出它的组成，如下图：
注意所有上面的代码是对Test接口进行实现的。由于TestCase和TestSuit两者都符合Test接口，我们可以通过addTestSuite递归地将TestSuite再组合成TestSuite，这样将构成树形结构。所有开发者都能够创建他们自己的TestSuit。测试人员可创建一个组合了这些套件的TestSuit来运行它们所有的TestCase。
public class AllTests extends TestCase {
public AllTests(String s) {
super(s);
}
public static Test suite() {
TestSuite suite1 = new TestSuite(我的测试TestSuit1);
TestSuite suite2 = new TestSuite(我的测试TestSuit2);
suite1.addTestSuite(untitled6.Testmath.class);
suite2.addTestSuite(untitled6.Testmulti.class);
suite1.addTest(suite2);
return suite1;
}
}
其结构如下图
3.3.4 效果
我们来考虑经过使用Composite模式后给系统的架构带来了那些效果：
l 简化了JUnit的代码JUnit可以统一处理组合结构TestSuite和单个对象TestCase。使JUnit开发变得简单容易，因为不需要区分部分和整体的区别，不需要写一些充斥着if else的选择语句。
l 定义了TestCase对象和TestSuite的类层次结构基本对象TestCase可以被组合成更复杂的组合对象TestSuite，而这些组合对象又可以被组合，如我们上个例子，这样不断地递归下去。客户代码中，任何使用基本对象的地方都方便的使用组合对象，大大简化系统维护和开发。
l 使得更容易增加新的类型的TestCase，如很下面介绍的Decorate模式来扩展TestCase的功能
l 使设计变得更加一般化。
3.4 Template Method（模板方法）
3.4.1 问题
在实际的测试中，为了测试业务逻辑，必须构造一些参数或者一些资源，然后才可进行测试，最后必须释放这些系统资源。如测试数据库应用时，必须创建数据库连接Connection，然后执行数据库的操作，最后实现释放数据库的连接。如下代码：
public void testUpdate(){
// Load the Oracle JDBC driver
DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
String url = jdbc:oracle:thin:@localhost:1521:ORA91;
// Connect to the database
Connection conn = DriverManager.getConnection (url, hr, hr);
PreparedStatement pstmt =
conn.prepareStatement (insert into PersonTab values (?));
// Bind the Person object
pstmt.setObject (1, person, OracleTypes.JAVA_STRUCT);
// Execute the insertion
pstmt.executeUpdate ()
// Disconnect
conn.close ();
}
其实这种情况很多，如测试EJB时，必须进行JNDI的LookUp，获得Home接口，其他的情况初始化参数等。可是如果我们在一个TestCase中有几个测试方法，例如测试对数据库的Insert，Update，Delet e，Select等操作，这些操作必须在每个方法中都首先获得数据库连接connection，然后测试业务逻辑，最后再释放连接。这样就增加了开发人员的工作，反复的书写这些代码，与JUnit当初的设计目标不一致？怎样解决这个问题？
3.4.2 模式的选择
接下来要解决的问题是给开发者一个便捷的“地方”，用于放置他们的初始化代码，测试代码，和释放资源的代码，类似对象的构造函数，业务方法，析构函数一样。并且必须保证每次运行测试代码之前，都运行初始化代码，最后运行释放资源代码，并且每一个测试的结果都不会影响到其它的测试结果。这样就达到了代码的复用，提供了开发人员的效率。
Template Method（模板方法）比较好地涉及到我们的问题。摘引其意图，“定义一个操作中算法的骨架，并将一些步骤延迟到子类中。Template Method使得子类能够不改变一个算法的结构便可重新定义该算法的
某些特定步骤。”这完全恰当。这样可以使测试者能够分别来考虑如何编写初始化和释放代码，以及如何编写测试代码。不管怎样，这种执行的次序对于所有测试都将保持相同，而不管初始化代码如何编写，或测试代码如何编写。
Template Method（模板方法）静态结构如下图所示：
这里设计到两个角色，有如下责任
l AbstractClass 定义多个抽象操作，以便让子类实现。并且实现一个具体的模板方法，它给出了一个顶级逻辑骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类里实现。模板方法也有可能调用一些具体的方法。
l ConcreteClass 实现父类的抽象操作方法，它们是模板方法的组成步骤。每一个AbstractClass可能有多个ConcreteClass与之对应，而每一个ConcreteClass分别实现抽象操作，从而使得顶级逻辑的实现各不相同。
3.4.3 实现
于是我们首先把TestCase分成几个方法，哪些是抽象操作以便让开发人员去实现，哪个是具体的模板方法，现在我们来看TestCase源码
public abstract class TestCase extends Assert implements Test {
//抽象操作，以便让子类实现
protected void setUp() throws Exception {
}
//抽象操作，以便让子类实现
protected void runTest() throws Throwable {
}
//抽象操作，以便让子类实现
protected void tearDown() throws Exception {
}
//具体的模板方法，定义出逻辑骨架
public void runBare() throws Throwable {
setUp();
try {
runTest();
}
finally {
tearDown();
}
}
}
setUp方法定义成protected让开发人员实现，去初始化测试信息，如数据库的连接，EJB Home接口的JNDI查找等信息，而tearDown方法则是实现测试完成后的资源释放等清除操作。RunTest方法则是开发人员实现的测试业务逻辑。最后TestCase的方法runBare则是模板方法，它实现了测试的逻辑骨架，而测试逻辑的组成步骤setUp, runTest, teardown,推迟到具体的子类实现，如一个具体的测试类
public class TestHelloWorldTestClientJUnit1 extends TestCase {
public void setUp() throws Exception {
super.setUp();
initialize();
create();
}
public void testGetMessage() throws RemoteException {
String strMsg = Hello World;
assertNotNull(ERROR_NULL_REMOTE, helloWorld);
this.assertEquals(strMsg,helloWorld.getMessage());
}
public void tearDown() throws Exception {
helloWorldHome = null;
helloWorld = null;
super.tearDown();
}
}
研究看它们的类图：
3.4.4 效果
我们来考虑经过使用Template Method模式后给系统的架构带来了那些效果：
l 在各个测试用例中的公共的行为（初始化信息和释放资源等）被提取出来，可以避免代码的重复，简化了开发人员的工作。
l 在TestCase中实现一个算法的不变部分，并且将可变的行为留给子类来实现。增强了系统的灵活性。使JUnit框架仅负责算法的轮廓和骨架，而测试的开发人员则负责给出这个算法的各个逻辑步骤。
3.5 Adapter（适配器）
3.5.1 问题
我们已经应用Command模式来表现一个测试。Command依赖于一个单独的像execute()这样的方法（在TestCase中称为run()）来对其进行调用。这个简单接口允许我们能够通过相同的接口来调用一个command 的不同实现。
如果实现一个测试用例，就必须实现继承Testcase，然后实现run方法，实际是（testRun），然而这样我们就把所有的测试用例都实现相同类的不同方法，这样的结果就会造成产生大量的子类，使系统的测试维护相当困难，并且setUp和tearDown仅为这个testRun服务，其他的测试也必须完成相应的代码，从而增加了开发人员的工作量，怎样解决这个问题？
为了避免类的急剧扩散，试想一个给定的测试用例类（testcase class）可以实现许多不同的方法，每一个方法都有一个描述性的名称，如testMoneyEquals或testMoneyAdd。这样测试案例并不符合简单的command 接口。因此又带来另外一个问题就是，使所有测试方法从测试调用者的角度（JUnit框架）上看都是相同的。怎样解决这个问题？
3.5.2 模式的选择
思考设计模式的适用性，Adapter（适配器）模式便映入脑海。Adapter具有以下意图“将一个类的接口转换成客户希望的另外一个接口”。这听起来非常适合。把具有一定规则的描述性方法如testMoneyEquals，转化为JUnit框架所期望的Command（TestCase的run）从而方便框架执行测试。Adapter模式又分为类适配器和对象适配器。类适配器是静态的实现在这里不适合使用，于是使用了对象适配器。
对象的适配器模式的结构如下图所示：
这里涉及到三个角色，有如下责任
l Target 系统所期望的目标接口
l Adaptee 现有需要适配的接口
l Adapter 适配器角色，把源接口转化成目标接口
3.5.3 实现
在实现对象的适配时，首先在TestCase中定义测试方法的命名规则必须是public void testXXXXX()这样我们解析方法的名称，如果符合规则认为是测试方法，然后使用Adapter模式把这些方法，适配成Command 的runTest方法。在实现时使用了java的反射技术，这样便可很容易实现动态适配。代码如下
protected void runTest() throws Throwable {
Method runMethod= null;
try {
//使用名称获得对象的方法，如testMoneyEquals，然后动态调用，适配成runTest方法
runMethod= getClass().getMethod(fName, null);
runMethod.invoke(this, new Class[0]);
} catch (Exception e) {
fail(+e.getMessage());
e.fillInStackTrace();
throw e;
}
}
在这里目标接口Target和适配器Adapter变成了同一个类,TestCase，而我们的测试用例，作为Adaptee，其结构图如下：
3.5.4 效果
我们来考虑经过使用Adapter模式后给系统的架构带来了那些效果：
l 使用Adapter模式简化测试用例的开发，通过按照方法命名的规范来开发测试，不需要进行大量的类继承，提高代码的复用，减轻测试人员的工作量
l 使用Adapter可以重新定义Adaptee的部分行为，如增强异常处理等
3.6 Observer（观察者）
3.6.1 问题
如果测试总是能够正确运行，那么我们将没有必要编写它们。只有当测试失败时测试才是有意义的，尤其是当我们没有预期到它们会失败的时候。更有甚者，测试能够以我们所预期的方式失败，例如通过计算一个不正确的结果；或者它们能够以更加吸引人的方式失败，例如通过编写一个数组越界。JUnit区分了失败（failures）和错误（errors）。失败的可能性是可预期的，并且以使用断言（assertion）来进行检查。而错误则是不可预期的问题，如ArrayIndexOutOfBoundsException。因此我们必须进行报告测试的进行状况，或者打印到控制台，或者是文件，或者GUI界面，甚至同时需要输出到多种介质。如JUnit提供了三种方式如Text,AWT,Swing这三种运行方式，并且JUnit需要提供方便的扩展接口，这样就存在对象间的依赖关系，当测试进行时的状态发生时（TestCase的执行有错误或者失败等），所有依赖这些状态的对象必须自动更新，但是JUnit又不希望为了维护一致性而使各个类紧密耦合，因为这样会降低它们的重用性，怎样解却这个问题？
3.6.2 模式的选择
同样需要思考设计模式的适用性，Observer（观察者）模式便是第一个要考虑的。Observer观察者模式是行为模式，又叫做发布－订阅(Publish-Subscribe)模式，模型－视图（Model/View）模式，源－监听器（Source/Listener）模式。具有以下意图“定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新”。这听起来非常适合需求。在JUnit测试用例时，测试信息一旦发生改变,如发生错误或者失败，结束测试等，各种输出就要有相应的更新，如文本输出就要在控制台打印信息，GUI则在图形中标记错误的信息等。
Observer（观察者）模式的结构如下图所示：
Observer（观察者）模式的角色
l Subject 提供注册和删除观察者对象的方法，可以保存多个观察者
l ConcreteSubject 当它的状态发生改变时，向它的各个观察者发出通知
l Observer 定义那些目标发生改变时需要获得通知的对象一个更新接口
l ConcreteObserver 实现更新接口
3.6.3 实现
首先定义Observer观察者的就是TestListener，它是一个接口，定义了几个方法，说明它监听的几个方法。如测试开始，发生失败，发生错误，测试结束等监听事件的时间点。由具体的类来实现。
/**
* A Listener for test progress
*/
public interface TestListener {
/**
* An error occurred.
*/
public void addError(Test test, Throwable t);
/**
* A failure occurred.
*/
public void addFailure(Test test, AssertionFailedError t);
/**
* A test started.
*/
public void startTest(Test test);
/**
* A test ended.
*/
public void endTest(Test test);
}
在JUnit里有三种方式来实现TestListener，如TextUI,AWTUi,SwingUI并且很容易使开发人员进行扩展，只需实现TestListener即可。下面看在TextUi方式是如何实现的，它由一个类ResultPrinter实现。
public class ResultPrinter implements TestListener {
PrintStream fWriter; * A test ended.
public PrintStream getWriter() {
return fWriter;
}
public void startTest(Test test) {
getWriter().print(.);
if (fColumn++ >= 40) {
getWriter().println();
fColumn= 0;
}
}
public void addError(Test test, Throwable t) {
getWriter().print(E);
}
public void addFailure(Test test, AssertionFailedError t) {
getWriter().print(F);
}
public void endTest(Test test) {
}
}
在JUnit中使用TestResult来收集测试的结果，它使用Collecting Parameter（收集参数）设计模式（The Smalltalk Best Practice Patterns中有介绍），它实际是ConcreteSubject，在JUnit中没有定义Subject,我们看它的实现
public class TestResult extends Object {
//使用Vector来保存，事件的监听者
protected Vector fListeners;
public TestResult() {
fListeners= new Vector();
}
/**
* Registers a TestListener
*/
public synchronized void addListener(TestListener listener) {
fListeners.addElement(listener);
}
/**
* Unregisters a TestListener
*/
public synchronized void removeListener(TestListener listener) {
fListeners.removeElement(listener);
}
/**
* Informs the result that a test will be started.
*/
public void startTest(Test test) {
final int count= test.countTestCases();
synchronized(this) {
fRunTests+= count;
}
for (Enumeration e= cloneListeners().elements(); e.hasMoreElements(); ) { ((TestListener)e.nextElement()).startTest(test);
}
}
/**
* Adds an error to the list of errors. The passed in exception
* caused the error.
*/
public synchronized void addError(Test test, Throwable t) {
fErrors.addElement(new TestFailure(test, t));
for (Enumeration e= cloneListeners().elements(); e.hasMoreElements(); ) { ((TestListener)e.nextElement()).addError(test, t);
}
}
/**
* Adds a failure to the list of failures. The passed in exception
* caused the failure.
*/
public synchronized void addFailure(Test test, AssertionFailedError t) {
JUnit设计模式分析 JUnit是一个优秀的Java单元测试框架，由两位世界级软件大师Erich Gamma 和Kent Beck共同开发完成。本文将向读者介绍在开发JUnit的过程中是怎样应用设计模式的。 关键词：单元测试JUnit 设计模式 1 JUnit概述 1.1 JUnit概述 JUnit是一个开源的java测试框架，它是Xuint测试体系架构的一种实现。在JUnit单元测试框架的设计时，设定了三个总体目标，第一个是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；第二个是使测试单元保持持久性；第三个则是可以利用既有的测试来编写相关的测试。所以这些目的也为什么使用模式的根本原因。 1.2 JUnit开发者 JUnit最初由Erich Gamma 和Kent Beck所开发。Erich Gamma博士是瑞士苏伊士国际面向对象技术软件中心的技术主管，也是巨著《设计模式》的四作者之一。Kent Beck先生是XP（Extreme Programmin g）的创始人，他倡导软件开发的模式定义，CRC卡片在软件开发过程中的使用，HotDraw软件的体系结构，基于xUnit的测试框架，重新评估了在软件开发过程中测试优先的编程模式。是《The Smalltalk Best Practice Patterns》、《Extreme Programming Explained》和《Planning Extreme Programming（与Martin Fowler合著）》的作者。 由于JUnit是两位世界级大师的作品，所以值得大家细细品味，现在就把JUnit中使用的设计模式总结出来与大家分享。我按照问题的提出，模式的选择，具体实现，使用效果这种过程展示如何将模式应用于JUnit。 2 JUnit体系架构 JUnit的设计使用以Patterns Generate Architectures（请参见Patterns Generate Architectures, Kent Beck and Ralph Johnson, ECOOP 94）的方式来架构系统。其设计思想是通过从零开始来应用设计模式，然后一个接一个，直至你获得最终合适的系统架构。 3 JUnit设计模式 3.1 JUnit框架组成 l 对测试目标进行测试的方法与过程集合，可将其称为测试用例。（TestCase）
创建型模式概述 创建型模式(Creational Pattern)对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。为了使软件的结构更加清晰，外界对于这些对象只需要知道它们共同的接口，而不清楚其具体的实现细节，使整个系统的设计更加符合单一职责原则。 模式动机 考虑一个简单的软件应用场景，一个软件系统可以提供多个外观不同的按钮（如圆形按钮、矩形按钮、菱形按钮等），这些按钮都源自同一个基类，不过在继承基类后不同的子类修改了部分属性从而使得它们可以呈现不同的外观，如果我们希望在使用这些按钮时，不需要知道这些具体按钮类的名字，只需要知道表示该按钮类的一个参数，并提供一个调用方便的方法，把该参数传入方法即可返回一个相应的按钮对象，此时，就可以使用简单工厂模式。模式定义 简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。 模式分析 将对象的创建和对象本身业务处理分离可以降低系统的耦合度，使得两者修改起来都相对容易。 在调用工厂类的工厂方法时，由于工厂方法是静态方法，使用起来很方便，可通过类名直接调用，而且只需要传入一个简单的参数即可，在实际开发中，还可以在调用时将所传入的参数保存在XML等格式的配置文件中，修改参数时无须修改任何Java源代码。 简单工厂模式最大的问题在于工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑，这一点与开闭原则是相违背的。 简单工厂模式的要点在于：当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。 简单工厂模式的不足 在简单工厂模式中，只提供了一个工厂类，该工厂类处于对产品类进行实例化的中心位置，它知道每一个产品对象的创建细节，并决定何时实例化哪一个产品类。简单工厂模式最大的缺点是当有新产品要加入到系统中时，必须修改工厂类，加入必要的处理逻辑，这违背了“开闭原则”。在简单工厂模式中，所有的产品都是由同一个工厂创建，工厂类职责较重，业务逻辑较为复杂，具体产品与工厂类之间的耦合度高，严重影响了系统的灵活性和扩展性，而工厂方法模式则可以很好地解决这一问题。 模式动机 考虑这样一个系统，按钮工厂类可以返回一个具体的按钮实例，如圆形按钮、矩形按钮、菱形按钮等。在这个系统中，如果需要增加一种新类型的按钮，如椭圆形按钮，那么除了增加一个新的具体产品类之外，还需要修改工厂类的代码，这就使得整个设计在一定程度上违反了“开闭原则”。 模式定义 工厂方法模式(Factory Method Pattern)又称为工厂模式，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它属于类创建型模式。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。 模式分析 工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了面向对象的多态性，工厂方
工厂系列模式的优缺点： 1.让用户的代码和某个特定类的子类的代码解耦 用户不必知道它所使用的对象是怎样创建的，只需知道该对象有哪些方法 2.抽象工厂模式可以为用户创建一系列相关的对象，使用户和创建这些对象的类脱耦 MVC模式是不是一种设计模式？为什么 MVC不是设计模式，应该是框架/架构模式，因为它的定义是抽象的，没有足够的细节描述使你直接去实现，而只能根据MVC的概念和思想，用几个设计模式组合实现。 举出一个生活中使用装饰者模式的例子，用程序实现思路 举个生活中的例子，俗话说“人在衣着马在鞍”，把这就话用装饰者模式的语境翻译一下，“人通过漂亮的衣服装饰后，男人变帅了，女人变漂亮了；”。对应上面的类图，这里人对应于ConcreteComponent,而漂亮衣服则对应于ConcreteDecorator； 设计模式如何分类，每一个类别都有什么特征？ 设计模式分为3类，分别是：创建型模式、行为型模式、结构型模式。 创建型特点：避免用户直接使用new运算符创建对象。 行为型特点：怎样合理的设计对象之间的交互通信，以及怎样合理的为对象分配职 结构型特点：主要用于处理类或对象的组合 Java jdk中使用了哪些设计模式 1.单例 2.静态工厂 3.工厂方法 4.抽象工厂 5.构造者 6.原型 7.适配器8桥接9.组合10.装饰器11.外观12.享元 页脚内容1
14.代理15.迭代器16.观察者17.协调者18.模板方法19.策略20.责任链21.命令22.空对象25.解释器 面向对象的设计原则有哪些？ 开闭原则、面向抽象的原则（依赖倒转原则）、多用组合少用继承原则、高内聚-低耦合原则。 观察者模式的推拉有什么不同？使用场景 推，具体主题将变化后的数据全部交给具体观察者。场景：当具体主题认为具体观察者需要这些变换后的数据时，往往采用推数据方式； 拉，具体主题不将变化后的数据交给具体观察者，而是提供获得这些数据的方法。场景：当具体主题不知道具体观察者是否需要这些变换后的数据时，往往采用拉数据的方式。 策略模式和工厂模式有什么不同？ 策略模式定义了一系列算法，将他们一个个封装，并且他们之间可以相互替换； 工厂模式定义一个创建对象的接口，让子类决定实例化哪一个类 5观察者模式的推拉有什么不同？适用场景 现在要说的分歧在这里： “推”的方式是指，Subject维护一份观察者的列表，每当有更新发生，Subject会把更新消息主动推送到各个Observer去。 “拉”的方式是指，各个Observer维护各自所关心的Subject列表，自行决定在合适的时间去Subject获取相应的更新数据。 “推”的好处包括： 页脚内容2
浅析23种软件设计模式 1、工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 2、建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。 4、原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。 5、单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。 6、适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。 7、桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。 8、合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。 9、装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。 10、门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。 11、享元模式：FL YWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存
摘要 本学期我学习了“设计模式-可复用面向对象软件的基础”这门课程，这次我采用的是命令模式+策略模式两种设计模式结合的案例。 分析的案例为：遥控器控制天花板上的吊扇，它有多种转动速度，当然也允许被关闭。假设吊扇速度：高、中、低、关闭。采用安全模式+策略设计模式。 报告整体结构为：两种设计模式的分析、理解，类图，实例分析、代码分析，总结。
目录 第一章命令模式+策略模式 (1) 1.1 命令模式 (1) 1.1.1 定义 (1) 1.1.2 命令模式的结构 (1) 1.1.3 角色 (1) 1.1.4 优点 (2) 1.1.5 缺点 (2) 1.5.6 适用情况 (2) 1.2 策略模式 (2) 2.1.1意图 (2) 2.2.2 主要解决问题 (2) 2.2.4 如何解决 (3) 2.2.5 关键代码 (3) 2.2.6优点 (3) 2.2.7 缺点 (3) 2.2.8 使用场景 (3) 2.2.9 注意事项 (3) 第二章案例分析 (4) 2.1 类图 (4) 2.2 测试分析 (4) 2.3 代码分析 (5) 2.2.1 命令模式模块代码 (5) 2.2.2 策略模式模块代码 (10) 第三章总结 (13)
第一章命令模式+策略模式 本案例用到的两种案例为安全模式+策略模式，因此在分析案例之前我先对两种设计模式进行分析。命令模式具体实现命令调控，策略模式定义一系列的算法,把它们一个个封装起来。 1.1 命令模式 1.1.1 定义 将来自客户端的请求传入一个对象，从而使你可用不同的请求对客户进行参 数化。用于“行为请求者”与“行为实现者”解耦，可实现二者之间的松耦合，以便 适应变化。分离变化与不变的因素。 1.1.2 命令模式的结构 命令模式是对命令的封装。命令模式把发出命令的责任和执行命令的责任 分割开，委派给不同的对象。 每一个命令都是一个操作：请求的一方发出请求要求执行一个操作；接收 的一方收到请求，并执行操作。命令模式允许请求的一方和接收的一方独立开来， 使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接 收，以及操作是否被执行、何时被执行，以及是怎么被执行的。 1.1.3 角色 Command 定义命令的接口，声明执行的方法。 ConcreteCommand 命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功 能来完成命令要执行的操作。 Receiver 接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够 实现命令要求实现的相应功能。 Invoker 要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。 这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使
全国计算机技术与软件专业技术资格（水平）考试2017年下半年系统架构设计师下午试卷I （考试时间14:00～16:30 共150 分钟） 1.在答题纸的指定位置填写你所在的省、自治区、直辖市、计划单列市的名称。 2.在答题纸的指定位置填写准考证号、出生年月日和姓名。 3.答题纸上除填写上述内容外只能写解答。 4.本试卷共5道题，试题一是必答题，试题二至试题五选答1 道。每题25 分，满分75 分。 5.解答时字迹务必清楚，字迹不清时，将不评分。 6.仿照下面例题，将解答写在答题纸的对应栏内。 例题 2017 年下半年全国计算机技术与软件专业技术资格（水平）考试日期是（1）月（2）日。 因为正确的解答是“11 月 4 日”，故在答题纸的对应栏内写上“11”和“4”（参看下表）。
试题一 阅读以下关于软件架构评估的叙述，在答题纸上回答问题1和问题2. 【说明】 某单位为了建设健全的公路桥梁养护管理档案，拟开发一套公路桥梁在线管理系统。在系统的需求分析与架构设计阶段，用户提出的需求、质量属性描述和架构特性如下: (a) 系统用户分为高级管理员、数据管理员和数据维护员等三类； (b) 系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御； (c) 正常负载情况下，系统必须在0.5 秒内对用户的查询请求进行响应； (d) 对查询请求处理时间的要求将影响系统的数据传输协议和处理过程的设计； (e) 系统的用户名不能为中文，要求必须以字母开头，长度不少于5个字符； (f) 更改系统加密的级别将对安全性和性能产生影响； (g) 网络失效后，系统需要在10 秒内发现错误并启用备用系统； (h) 查询过程中涉及到的桥梁与公路的实时状态视频传输必须保证画面具有1024*768的分辨率，40帧/秒的速率； (i) 在系统升级时，必须保证在10 人月内可添加一个新的消息处理中间件； (j) 系统主站点断电后，必须在3 秒内将请求重定向到备用站点； (k) 如果每秒钟用户查询请求的数量是10 个，处理单个请求的时间为30 毫秒，则系统应保证在1秒内完成用户的查询请求； (l) 对桥梁信息数据库的所有操作都必须进行完整记录； (m) 更改系统的Web 界面接口必须在4 人周内完成； (n) 如果"养护报告生成"业务逻辑的描述尚未达成共识，可能导致部分业务功能模块规则的矛盾，影响系统的可修改性 (O) 系统必须提供远程调试接口，并支持系统的远程调试。 在对系统需求，质量属性描述和架构特性进行分析的基础上，系统的架构师给出了三个候选的架构设计方案，公司目前正在组织系统开发的相关人员对系统架构进行评估。 【问题1】(12 分) 在架构评估过程中，质量属性效用树(utility tree) 是对系统质量属性进行识别和优先级
《UML与设计模式》实验报告
角色之间的关系 （4）绘制用例之间的包含和扩展关系（给出UML用例图） 用例之间如果存在包含关系，则通过拖拽“UML用例”标签页中的“用” 图标来连接两个用例；用例之间如果存在扩展关系，则通过拖拽“UML 用例”标签页中的“扩展”图标来连接两个用例。 用例图作为一种UML模型元素，也必须用包来组织。本例中将两个用例图都放到了用例模型顶层包中，还可以用注释元素对用例图作简单说明。 结果：
用例之间的包含和扩展关系 （5）每个用例进行用例描述 用例增加课程 参与者管理员 操作流（1）管理员选择进入管理界面，用例开始 （2）系统提示输入管理员密码 （3）管理员输入密码 （4）系统检验密码 （5）进入管理界面，系统显示当前所建立全部课程信息 （6）管理选择添加课程，管理输入新课程信息 （7）系统验证是否与已有课程冲突 （8）系统添加新课程，并提示添加成功 （9）系统回到管理主界面，显示所有课程，用例结束。 用例修改课程 参与者管理员 操作流（1）管理员选择进入管理界面，用例开始 （2系统提示输入管理员密码 （3）管理员输入密码 （4）系统检验密码 （5）进入管理界面，系统显示当前所建立全部课程信息
思考题【思考问题】 1．绘制用例图的步骤是什么？ 创建新的UML用例图 1.在“体系结构”菜单上，单击“新建关系图”。 2.在“模板”下，单击“UML 用例图”。 3.命名该关系图。 4.在“添加到建模项目”中，从您的解决方案中选择一个现有建模项目，或者选择“创建新的建模项目”，然后单击“确定” 绘制UML用例图 1.将“子系统”边界从工具箱拖到关系图中，它可以表示整个系统或其中的主要组件。 如果不希望描述系统或其组件支持哪些用例，用例图中可以不绘制系统边界。 根据需要，拖动系统的四角将其扩大。 对其适当地重命名。 2.将“参与者”从工具箱拖到关系图中（将其放在所有系统边界之外）。 参与者表示与您的系统进行交互的各类用户、组织和外部系统。 重命名这些参与者。例如：“顾客”、“餐馆”、“信用卡机构”。 3.将“用例”从工具箱拖到适当的系统中。 用例表示参与者在系统的帮助下所执行的活动。 使用参与者自身能够理解的名称重命名这些用例。不要使用与代码有关的名称。例如：“订餐”、“付餐费”、“送餐”。 从主要的事务（如“订餐”）开始，直到后面较小的事务（如“点菜”）为止。 将每个用例放入支持它的系统或主要子系统（忽略任何只与用户有关的外观模式或组件模式）。 可以在系统边界外绘制用例，以表明系统（可能在特定版本中）不支持该用例。 4.单击工具箱上的“关联”，然后单击用例，再单击该用例的参与者。以此方式将每个参与者与其用例相链接。
架构分析与设计模 式
摘要：一个设计模式是针对某一类问题的最佳解决方案，而且已经成功应用于许多系统的设计中，它解决了在某种特定情境中重复发生的某个问题，因此设计模式能够被定义为：设计模式是从许多优秀的软件系统中总结出成功的可复用的设计方案。 1.关键字：工厂方法模式、简单的程序实现、架构分析、设计模 式 工厂方法模式 2.工厂方法模式的介绍 工厂方法(Factory Method)模式的意义是定义一个创立产品对象的工厂接口，将实际创立工作推迟到子类当中。核心工厂类不再负责产品的创立，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一步抽象化的好处是使得工厂方法模式能够使系统在不修改具体工厂角色的情况下引进新的产品。 1.1工厂方法模式角色与结构 抽象工厂(Creator)角色：是工厂方法模式的核心，与应用程序无关。任何在模式中创立的对象的工厂类必须实现这个接口。 具体工厂(Concrete Creator)角色：这是实现抽象工厂接口的具体工厂类，包含与应用程序密切相关的逻辑，而且受到应用程序调用以创立产品对象。
抽象产品(Product)角色：工厂方法模式所创立的对象的超类型，也就是产品对象的共同父类或共同拥有的接口。在上图中，这个角色是Light。 具体产品(Concrete Product)角色：这个角色实现了抽象产品角色所定义的接口。某具体产品有专门的具体工厂创立，它们之间往往一一对应。 1.2工厂方法模式的应用 工厂方法经常见在以下两种情况中: 第一种情况是对于某个产品，调用者清楚地知道应该使用哪个具体工厂服务，实例化该具体工厂，生产出具体的产品来。Java Collection中的iterator() 方法即属于这种情况。 第二种情况，只是需要一种产品，而不想知道也不需要知道究竟是哪个工厂为生产的，即最终选用哪个具体工厂的决定权在生产者一方，它们根据当前系统的情况来实例化一个具体的工厂返回给使用者，而这个决策过程这对于使用者来说是透明的。 1.3工厂方法模式的适用环境 在以下情况下能够使用工厂方法模式： （1）一个类不知道它所需要的对象的类：在工厂方法模式中，客户端不需要知
龙源期刊网 https://www.doczj.com/doc/255716689.html, 软件设计模式研究及应用 作者：范伟 来源：《山东工业技术》2015年第20期 摘要：采取有效模式，提高软件设计水平，使其得到更好应用是非常重要的一项工作。文章介绍了软件设计模式的种类和要素，分析软件设计模式的应用范围和应用方法，希望能为实际工作提供指导与借鉴，能引起人们对该问题的关注。 关键词：软件设计；设计模式；软件应用 0引言 在软件设计过程中，采取有效的设计模式，严格按照规范流程开展设计是十分必要的。但目前设计工作中存在一些问题与不足，影响软件设计和应用。今后应采取完善措施，把握每个要点，注重技术创新和完善，促进设计水平提高。 1软件设计模式的种类 根据工作类型和应用范围的不同，软件设计模式的具体种类也不一样，主要类型包括以下几种。 （1）创建型模式。与对象创建有关，描述怎样创新一个对象，将对象创建的具体细节隐藏，让程序代码不依赖具体对象，设计对象实例，促进设计水平提高。常用工厂方法、生成器模式、原型模式、单件模式等，实际工作中，用定义创建对象接口，复制原型创建新对象等方法，完成软件模式设计工作。 （2）行为型模式。主要内容为算法对象间责任分配问题，描述对象或类的模型，并包括他们之间的通信模式，重点关注的是对象间的联系方式，常用中介者模式、观察者模式等。 （3）结构型模式。该模式所描述的是一系列将类和对象进行组合的问题，通过组合，结合具体工作需要，从而构建更大的类和对象。重点是结构化方式，并不是如何构造这些类。常用结构型类模式，利用接口或类的继承来实现。还有一种结构型对象模型，对设计对象进行组合和加工，完成设计和加工任务，满足具体工作需要。 2软件设计模式的要素 具体设计过程中，应该严格把握每个要素，重视每个流程的质量控制，促进设计水平提高。
谈到用说话，更多是说话惯用法，而非计划形式，他们是不同层面的观点，MVC那就扯得更远了，计划形式是针对利用top down上去，而非一种特定的说话，假如为说话而形式，为形式而形式那便是刻舟求剑。广义的计划形式是针对面向工具这种说话，C 用的啰嗦一点，模仿出工具干系，应用GOF总结的计划形式是没成绩的，但干系假如整地过于繁杂就违反C 说话精干的特色，就不要用C了。广义的是针对一种编程范式中的形式，象C这种命令式说话，模仿函数式编程照样力不从心，函数式里的形式就用不来。 C的惯用法重要会合在macro, 用好了会感到代码清楚，反复很少。C不是OO说话，但编程中能够利用一些OO思惟。 好比工具的观点，C++的class便是struct的升级版，所以在C中一个struct变量能够视为一个工具实例。 好比有一个玩家工具布局体struct Player，内有属性HP。承继玩家的，有兵士和法师。 那末能够这么写： struct Player { int HP;//血量 }; struct Warrior { struct Player base; int Attack;//攻击力 int Defensive;//进攻力 }; struct Mage { struct Player base; int MP;//邪术值 int Range;//施法规模 }; //玩家挂了吗？ int Player_IsDead(struct Player* player) { return (player->HP==0) ? 1 : 0; } //吃血 void Player_DrinkRedBottle(struct Player* player, int bottle_level) { if( bottle_level == 1 ) player->HP += 100;//小瓶 else if( bottle_level == 2 ) player->HP += 500;//大瓶 } struct Warrior w; struct Mage m; //兵士没挂就吃个小血瓶 if( !Player_IsDead((struct Player*)&w) ) { Player_DrinkRedBottle((struct Player*)&w, 1); } // if( !Player_IsDead((struct Player*)&m) ) { Player_DrinkRedBottle((struct Player*)&m, 1);
追MM与设计模式（23种设计模式巧妙解析，趣味理解） 2017-04-26程序员共读 在网络上流畅很广的一篇旧文，暂时没找到原作者，目前所看到的最早转载时间是 2005 年 2 月 28 日。作者用轻松 的语言，形象解释了 23 种模式，有很好的启发作用。 创建型模式 1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖） 建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。 工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。 4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要） 原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有
《设计模式》实验指导书 10学时 教师：张凯
实验一单例模式的应用 1 实验目的 1) 掌握单例模式（Singleton）的特点 2) 分析具体问题，使用单例模式进行设计。 2 实验内容和要求 很多应用项目都有配置文件，这些配置文件里面定义一些应用需要的参数数据。 通常客户端使用这个类是通过new一个AppConfig的实例来得到一个操作配置文件内容的对象。如果在系统运行中，有很多地方都需要使用配置文件的内容，系统中会同时存在多份配置文件的内容，这会严重浪费内存资源。 事实上，对于AppConfig类，在运行期间，只需要一个对象实例就够了。那么应该怎么实现呢？用C#控制台应用程序实现该单例模式。绘制该模式的UML 图。
实验二工厂模式的应用 1 实验目的 1) 掌握工厂模式（Factory）的特点 2) 分析具体问题，使用工厂模式进行设计。 2 实验内容和要求 有一个OEM制造商代理做HP笔记本电脑(Laptop)，后来该制造商得到了更多的品牌笔记本电脑的订单Acer，Lenovo，Dell，该OEM商发现，如果一次同时做很多个牌子的本本，有些不利于管理。利用工厂模式改善设计，用C#控制台应用程序实现该OEM制造商的工厂模式。绘制该模式的UML图。
实验三抽象工厂模式的应用 1 实验目的 1) 掌握抽象工厂模式（Abstract Factory）的特点 2) 分析具体问题，使用抽象工厂模式进行设计。 2 实验内容和要求 麦当劳（McDonalds）和肯德基（KFC）快餐店都经营汉堡（Hamburg）和可乐（Cola），用C#控制台应用程序实现这两个快餐店经营产品的抽象工厂模式。绘制该模式的UML图。
太原师范学院 实验报告 Experimentation Report of Taiyuan teachers College 系部计算机系年级课程设计模式实训教程 姓名学号日期2018.03.03 项目 Factory Method设计模式 一、实验目的 定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。 框架使用抽象类定义和维护对象之间的关系。这些对象的创建通常也由框架负责。考虑这样一个应用框架，它可以向用户显示多个文档。在这个框架中，两个主要的抽象是类Application和Document。这两个类都是抽象的，客户必须通过它们的子类来做与具体应用相关的实现。 二、实验原理 试验要求包含典型的 Factory Method结构。 程序能够明确表达设计思想。 三、实验仪器及材料 操作系统： Windows，linux； 开发工具： VC； Java，C# 四、实验方法 设计一个Factory Method案例并实现，并撰写设计报告。
五、实验记录及数据处理 interface Log{ public void writeLog(); } //文件日志记录器：具体产品 class FileLog implements Log{ @Override public void writeLog() { System.out.println("文件日志记录。"); } } //数据库日志记录器：具体产品 class DatebaseLog implements Log{ @Override public void writeLog() { System.out.println("数据库日志记录。"); } } //日志记录器工厂接口：抽象工厂 interface LogFactory{ public Log createLog(); } //文件日志记录器工厂类：具体工厂 class FileLogFactory implements LogFactory{ @Override public Log createLog() { return new FileLog(); } } //数据库日志记录器工厂类：具体工厂 class DatabaseLogFactory implements LogFactory{ @Override public Log createLog() {
一、1. 设计模式一般用来解决什么样的问题： A.同一问题的不同表相 2. 下列属于面向对象基本原则的是： C.里氏代换 3. Open-Close原则的含义是一个软件实体：A.应当对扩展开放，对修改关闭. 4. 当我们想创建一个具体的对象而又不希望指定具体的类时，使用（A）模式。A.创建型 5. 要依赖于抽象不要依赖于具体。即针对接口编程不要针对实现编程：（D）依赖倒转原则 6. 依据设计模式思想,程序开发中应优先使用的是( A )关系实现复用。A, 委派 7. 设计模式的两大主题是( D ) D.系统复用与系统扩展 8. 单体模式中,两个基本要点(AB)和单体类自己提供单例A .构造函数私有 B.唯一实例 9. 下列模式中,属于行为模式的是( B ) B观察者 10. “不要和陌生人说话”是( D )原则的通俗表述 D.迪米特 1. 软件体系结构是指一个系统的有目的的设计和规划，这个设计规划既不描述活动，也不描述系统怎样开发，它只描述系统的组成元素及其相互的交互协作。2．一个UML模型只描述了一个系统要做什么，它并没告诉我们系统是怎么做。3．接口是可以在整个模型中反复使用的一组行为，是一个没有属性而只有方法的类。4．多重性指的是，某个类有多个对象可以和另一个类的一对象关联。 5．当一个类的对象可以充当多种角色时，自身关联就可能发生。 6．在泛化关系中，子类可以替代父类。后前者出现的可以相同地方。反过来却不成立。7．最通常的依赖关系是一个类操作的形构中用到了另一个类的定义。8．组成是强类型的聚集，因为聚集中的每个部分体只能属于一个整体。9．实现的符号和继承的符号有相似之处，两者的唯一差别是实现关系用虚线表示，继承关系用实线表示。 10. 设计模式中应优先使用对象组合而不是类继承。 1.适配器模式属于创建型模式结构型（ F ） 2.在设计模式中，“效果”只是指“原因和结果”（ T ） 3.设计模式使代码编制不能真正工程化（ T ） 4.面向对象语言编程中的异常处理，可以理解为责任链模式（T ） 5.反模式就是反对在软件开发过程中使用设计模式分析：反模式用来解决问题的带有共性 的不良方法（F ） 1.什么是设计模式？设计模式目标是什么？ 答：设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解，保证代码可靠性。2.设计模式中一般都遵循的原则有什么？ 答：开闭原则、根据场景进行设计原则、优先组合原则、包容变化原则 3.“Gang of Four”针对“创建优秀面向对象设计”建议了哪些策略？ 答：针对接口编程、优先使用对象组合而不是类继承，找到并封装变化点。 4.面向对象系统中功能复用的两种最常用技术是什么？ 答：类继承和对象组合，类继承允许你根据其他类的实现来定义一个类的实现。父类的内部细节对子类可见。类继承是在编译时刻静态定义的，且可直接使用，类继承可以较方便地改变被复用的实现。对象组合是类继承之外的另一种复用选择。新的更复杂的功能可以通过组装或组合对象来获得。对象组合要求被组合的对象具有良好定义的接口。 5.只根据抽象类中定义的接口来操纵对象有什么好处？ 答：1) 客户无须知道他们使用对象的特定类型，只须对象有客户所期望的接口。 2) 客户无须知道他们使用的对象是用什么类来实现的，他们只须知道定义接口的抽象类。
三、题目预测 填空题： 1.请从外观、组合、工厂方法、模板方法、观察者、单件、抽象工厂、命令、迭代器、代理、适配器模式中选择7种填入下列的空缺中。P610 1) 工厂方法模式中，父类负责定义创建对象的公共接口，子类决定要创建的具体类是哪一个。 2) 抽象工厂模式提供一系列相关或相互依赖对象的接口而无需指定它们具体的类。 3) 单件模式确保某一个类仅有一个实例，并自行实例化并向整个系统提供这个实例。 4) 组合模式将对象组合成树形结构以表示“部分-整体”的层次结构。使得用户对单个对象和组合对象的使用具有一致性。 5) 外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用，为子系统中的一组接口提供一个一致的界面，简化了一群类的接口。 6) 观察者模式定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新，也就是让对象能在状态改变时被通知。 7) 模板模MVC模型式定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。 8) 迭代器模式在对象的集合之中游走，而不暴露集合的实现。 9) 代理模式包装对象，以控制对比对象的访问。 10) 适配器模式封装对象，并提供不同的接口。 2.工厂模式分为(简单工厂),(工厂方法),(抽象工厂)三种类型。 3.适配器模式，分为类的适配器和对象的适配器两种实现。其中类的适配器采用的是（继承）关系，而对象适配器采用的是（组合聚合）关系。 4.设计模式的基本要素有（名字），（意图），（问题），（解决方案），（参与者与协作者），（实现），（一般性结构）。 5.MVC模型的基本工作原理是基于(观察者)模式，实现是基于（命令）模式 6.面向对象的六条基本原则包括：开闭原则，里式代换原则，合成聚合原则以及（依赖倒转），（迪米特法则）（接口隔离）。 7．当我们想用不同的请求对客户进行参数化时，可以使用（命令）模式。
项目学习及其特点 项目学习（Project- based Learning，简称PBL）起源于美国，著名教育家克伯屈于1918年首次提出“项目”的概念，它指“学生通过完成与真实生活密切相关的项目进行学习，是一种充分选择和利用最优化的资源，在实践体验、内心吸收、探索创新中获得较为完整而具体的知识，形成专门的技能并获得发展的实践活动。”项目学习是一套从学生已有经验出发，在复杂、真实的生活情景中引导学生自主地进行问题分析与探究，通过制作作品来完成自己知识意义建构的教学模式。项目学习属于研究性学习的范畴，注重培养学生发现问题、分析问题、进而解决问题的能力，但较之于研究性学习，项目学习更强调来源于真实情景中的任务，更注重学生实际动手能力和团队合作精神，更具有实践性和操作性。PBL作为一种新型的教学模式，具有以下特点： （1）主题明确。一个项目需要有一个明确特定的主题，学生围绕该主题展开实践探究，在活动中建构起新的知识体系，掌握一定的技能。 （2）情境真实而具体。按学习的需求立项，一般取材于生活，学习者面对的是真实而具体的问题，且往往需要在活动结束之际产生一个或一系列作品。 （3）内容上体现综合性。项目学习需要综合利用多方面的知识和技能来解决项目中的问题和任务。在某些项目中还需要用到多门学科或多个领域的知识和技能。 （4）学习方式多样化且强调协作，项目学习往往需要通过实践体验、学习书本知识、考察调研等多种途径来完成，同时过程中强调同伴之间、与教师或其他人之间的合作努力。 （5）学习手段数字化、网络化。项目学习可以充分利用多媒体和网络等信息技术，进行学习，且支持学生使用各种数字化的认知工具和信息资源来陈述他们的观点。 从前面的项目学习定义以及特点我们可以很容易发现，项目学习体现了“以学习者为中心”的教育理念，有利于促进学生实践能力的提高与综合素质的发展，这与2001年教育部颁布《基础教育改革纲要（试行）》所提出的“改变课程实施过程过于接受学习、死记硬背、机械训练的现状，倡导学生主动参与、乐于探究、勤于动手，培养学生搜集和处理信息的能力，获取新知识的能力，分析和解决问题的能力及交流合作的能力。”因而在中小学教学中有着广泛的研究和应用。在具体实施中，以下一些模式均为项目学习提供了不同的设计框架。 一、研究性学习模式 “研究性学习”是教育部2000年1月颁布的《全日制普通高级中学课程计划（试验修订稿）》中综合实践活动板块的一项内容，也是《基础教育课程改革纲要（试行）》所规定的重
交互设计案例分析 实验三界面设计一般原则的实践案例 【实验目的】 通过上机实践体会界面设计的一般原则，从而增加对相关的界面设计模式的理解。【实验环境】 IE 5.0以上, 可以上网。 【实验要求】 参照实验指导给出的界面设计案例，自己去发现符合界面设计原则的案例。 案例来源可以是任何可以获取到的系统或应用。例：淘宝、百度、新浪、QQ、微信、人人网、相关网关、游戏、移动应用等。 尽可能是找正向案例，如果有合适的反向案例也可。 将“你的发现”记录下，有图有文有真相。 【实验指导】 (一) 界面一致性 设计模式 界面设计在同一个系统内保持一致；界面设计与常用软件、用户使用习惯保持一致 ?同一系统内界面风格保持一致。每种控件的只有一种样式：窗口、按钮、菜单、 对话框等；同一系统内字体、颜色、布局、位置、尺寸、间距等尽可能保持一种格 式。
界面风格（例：菜单组织、快捷键设计等）与常用软件、用户使用习惯保持一致 你的发现 ※导航一般会在页面的左侧和上方，界面风格与常用软件、用户使用习惯保持一致，同一系统内界面风格保持一致。
(二) 快捷方式 设计模式 对常用操作、烦琐的操作、突发状态下的操作、最近频繁操作等提供快捷操作方式。 ?提供快捷方式，更快的操作入口，以减少查找时间。 ?最近频繁使用列表，更快的操作入口，以减少查找时间。 ?操作过程和步骤优化，去除不必要的按钮，以减少交互次数。 ?一键式、打包操作，以减少操作过程的烦琐 ?批处理操作，以减少重复操作。
提供默认值（例：当天日期、用户常用选项等），以减少不必要的用户输入 你的发现 ※发邮件时，发件人自动显示，无需格外备注 (三) 错误处理 设计模式 对容易误操作的、操作会带来不良后果的、重大的错误必须要提供错误处理
软件设计最佳实践和案例分析 --如何提高软件灵活性/可扩展性以及复用性 几十年来，软件开发实践一直被惊人的低成功率所困扰。作为软件设计师，你知道现在软件开发悲剧的根源在哪里吗？如果你连根源都不知道在哪里？你怎样知道去解决呢？ 在软件开发过程之中，会遇到各种各样的问题，原因归结起来主要根源有两个方面，一个是复杂性，一个是变化性。软件的规模越大，各个部分之间的牵连越复杂，更改也就越难。如果软件简单并且规模小，更改还比较容易。但是随着用户业务复杂，几乎所有的软件的任务规模都会越来越大。 如果只是增加软件功能，也不会引起那么多悲剧。可是，伴随着软件复杂性增加，需求的变更几乎是不可避免。在需求分析时，即便客户同意了需求分析书的签字，可一旦见到了真实的系统。客户还是感觉不对劲，仍然要求必须修改。 伴随着软件越来越复杂，对软件的变更需求越来越频繁，更改所需求的花费越来越大。我们软件开发人员的悲剧就诞生了。 很多软件的设计往往是大泥球式的设计，指结构杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。在现今软件开发日趋复杂的情况下，围绕着如何安排、规划这些活动的次序、周期和时间，人们提出过各种各样的软件开发方法模型。比如目前流行的敏捷/RUP等等. 但是软件质量最终还是依赖较强责任心和能力的设计师。除非如此，不管是敏捷是非敏捷，软件设计的问题根本不能解决。因此持续关注优秀技能和良好的设计，才可以真正实现敏捷。 我们大多在一线的设计师,不了解设计的基本原则/模式,但是可惜当他知道一些原则和模式后,却已经变成了管理者(项目经理,产品经理等管理岗位),不在从事设计的工作. 这真是业界悲哀的事情.我们课程重点关注软件设计师技能, 这是本课程的设置的目的.课程总结了多年项目开发的实战经验，让学员体会在软件系统设计过程中提高能力。 一、课程特色 一般的书籍和培训,往往是介绍设计过程,设计原则和模式,之后再给出几个简单的在理想情况下的应用.要么是拿出最终设计来讲解,然后告诉他的设计的是多么灵活,多么的好. 但是当你课程结束后,回到工作之中却发现情况是完全的不一样,这时你只有束手无策.本课程注重实战,采用案例贯穿方式完成讲解理论，让学员体验软件设计的思索,权衡,折中,选择的痛苦过程，首先提出真实项目的需求,然后学员开始动手设计,最终讲师和你一起思索,一起探讨,一起权衡,一起验证.