软件设计模式终极版复习题.doc

\(^o^)/~萤火虫\(^o^)/~
1.简述“开—闭”原则的基本思想。请举出一个使用了软件“开—闭”原则的软件设计模式，其中何处体现了“开—闭”原则。
答：“开—闭”原则：软件实体应当对扩展开放，而对修改关闭，“开-闭”原则要求软件系统能够在不需要修改原有类的基础上，通过增加类达到扩展功能的目的。
Abstract factory体现了这个原则，如果想增加一类新的products，只需在product类体系中增加各个products，然后在factory类体系结构中增加一个concrete factory就可以了，而不需要对现有类做任何修改，The Open-closed principle[ocp]在不改动过模块源代码的情况下扩展模块的行为。
软件实体（类模块 函数等）应该是可以扩展的，但是不可以修改的。

2.简述依赖例转原则的基本思想。请举出一个使用了软件依赖原则的软件设计模式，其中何处体现了依赖原则。
答：依赖倒置原则的基本思想是：①高层模块不应该依赖于低层模块，二者都应该依赖于抽象。②抽象不应该依赖于细节，细节应该不依赖于抽象。Tomplate method就体现了这个原则，它定义了一个操作中的算法骨架，而将一些步骤延迟到子类中，template method使得子类不改变一个算法的结构，即可重定义该算法的某些特定步骤。

3.什么是单一职责原则？请举出一个使用了单一职责原则的软件设计模式，其中何处体现了单一职责原则。
答：基本思想：SRP使得一个类或一个模块承担的责任尽可能的少，使尽可能少的因素或动机影响该类或该模块，即增大类或模块的内聚性，减少其耦合度，SRP是所有原则中最简单的之一，也是最难正确运用的之一。
COMMAND模式体现了SRP原则，大多数类都是一组方法和相应的一组变量的结合，而该模式只是封装了一个没有任何变量的函数，它对函数的关注超过了类，将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化。

4.软件复用可采用类的继承方式和类的聚合方式，比较两者的优缺点。
答：聚合：一个对象拥有另一个对象或对另一个对象负责（即一个对象包含另一个对象或是另一个对象的一部分）并且聚合对象和其所有具有相同的生命周期（即所谓的“同生共死”关系）。
聚合复用优点：①容器类仅能通过被包含对象的接口来对其进行访问。②“黑盒”复用，因为被包含对象的内部细节对外是不可见。③包装性好。④实现上的相互依赖性比较小。⑤每一个类只专注于一项任务。⑥通过获取指定其他的具有相同类型的对象的使用，可以在运行期间动态地定义（对象的）组合。
聚合的缺点：①导致系统中的对象过多 ②为了能将多个不同的对象作为组合块来使用，必须仔细地对接口进行定义。
类继承：是一种通过扩展（一个已有对象的）实现，从而获得新功能的复用方法。
继承的优点①容易进行新的实现，因为其大多数可继承而来 ②易于修改或扩展那些被复用的实现。
继承的缺点：①破坏了封装性，因为这会将父类的实现细节暴露给子类 ②“白盒”复用，因为父类的内部细节对于子类而言通常是可见的 ③当父类的实现更改时，子类也不得不随之更改 ④从父类继承来的实现将不能在运行期间进行改变。

5.画出工厂方法模式的结构图。什么情况下适合使用工厂方发模式？

其中product：为工厂模式所要创建的对象类型定义一个接口。
Concrete product:实现product接口。
Creator：声明工厂方法（factory method）返回值为product的一个对象。

Concrete creator：覆写factory Method()，返回值为concrete product 的一个具体实例。
在下面情况下你可以考虑使用工厂方法模式：
1) 当客户程序不需要知道要使用对象的创建过程。
2) 客户程序使用的对象存在变动的可能，或者根本就不知道使用哪一个具体的对象。

6.画出合成模式（Composite）的结构图。举例说明一个可以应用合成模式的软件设计实例，说明其中各角色的作用。

实例：计算机和立体组合音响这样的设备经常被组装成一部分整体层次结构或者是容器层次结构，例如：底盘可以包含驱动装置和平面板，总线含有多个插件，机柜包括底盘总线等。这样结构很自然的用composite模式进行模拟。
Equipment类为在部分——整体层次结构中的所有设备定义一个接口。Equipment声明一些操作返回一个设备的属性，例如它的能是消耗和价格。子类为指定的设备实现了这些操作，Equipment还声明了一个Create Iterator 操作，该操作为访问它的零件返回一个Iterator ,这个操作的缺省实现返回一上NullIterator，它在空集上迭代。
Composite Equipment是包含其它设备的基类，它也是Equipment的子类。

7.简述门面模式（Facade）和中介者模式（Mediator）的基本思想，两者的差异何在？
答：门面模式（facade）又称外观模式。基本思想：为子系统中的一组接口提供一个一致的界面， Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
“中介者模式”基本思想：Mediator Pattern 中文译为“中介者模式”、“调停者模式”。调停者模式的定义是：用一个调停对象来封装一系列的对象交互。调停者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。简单点来说，将原来两个直接引用或者依赖的对象拆开，在中间加入一个“调停”对象，使得两头的对象分别和“调停”对象引用或者依赖。
两者的差异： 从目的上看，调停者模式与门面模式有些相似。 但是门面模式是介于客户程序与子系统之间的，而调停者模式是介于子系统与子系统之间的。这也注定了它们有很大的区别：门面模式是将原有的复杂逻辑提取到一个统一的接口，简化客户对逻辑的使用。它是被客户所感知的，而原有的复杂逻辑则被隐藏了起来。而调停者模式的加入并没有改变客户原有的使用习惯，它是隐藏在原有逻辑后面的，使得代码逻辑更加清晰可用。

8.简述观察者模式的基本思想，如何实现当目标对象发生变化时多个观察者对象的同步更新？画出他们之间的协作图。
（1）Observer（观察者）基本思想：对象间的一种一对多的依赖关系。当一个对象的状态发生变化时，所有依赖于它的对象都得到通知并自动更新。
（2）协作：当Concrete Subject发生任何可能导到其参观者与其本身状态不一致的改变时，它将通知它的各个观察者。在得到一个具体的目标改变通知后，Concrete Object对象可向目标对象查询信息，Concrete Object使用这个些信息以使它的状态与目标对象的状态一致。
（3）协作图：

9.举一适合使用State模式的例子。与不使用该模式相比，有哪些优点？
举例：抽象状态类定义了一个抽象方法“写程序”

与不使用该模式相比优点：
State模式将特定的状态相关的行为封装在一个类中，由于所有状态相关的代码都存在于某个concrete state中，所以通过定义新的子类可以很容易的增加新的状态和转换。

10.有哪些模式的使用可以使得类的复用性增强？说明你的理由。
策略模式（strategy） 属于对象行为型模式，主要定义一系列的算法，把这些算法一个个封装成拥有共同接口的单独的类，并使他们之间互换，客户端调用他们的时候互不影响。算法使用和算法分离，即将变化的具体算法封装起来，降低了代码的耦合度，算法提取起来，使算法得到重用。
中介者模式（mediator） 用一个调停对象来封装一系列的对象交互。调停者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。即，将原来的两个直接引用或者依赖的对象拆开，在中间加入一个“调停”对象，使得两头的对象分别和“调停”对象引用或者依赖。提高了原有系统的可读性，将原有系统的多对多转化为一对多，提高了代码的可复用性。
适配器（Adapter）模式 是的原本由于接口不兼容而不能再一起的那些类可以一起工作。如画图程序中，已实现绘制点，直线等功能。为了让客户程序在使用的时候不用关心不同定义，定义个抽象类规范接口，当去实现绘图时，发现系统其它地方已有制图实现，但是系统已有的方法与抽象类中规定方法不一样，这时候用适配器模式可以解决这问题。适配器模式是为了面向接口编程中更好的复用。

11.比较Adapter和Proxy模式使用上的异同之处。

适配器模式(Adapter)：将一个类的接口转换成客户希望的另外一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
代理模式有两个英文名字：Proxy Pattern 和 Surrogate Pattern。代理模式：为其他对象提供一种代理以控制对这个对象的访问。说白了就是，在一些情况下客户不想或者不能直接引用一个对象，而代理对象可以在客户和目标对象之间起到中介作用，去掉客户不能看到的内容和服务或者增添客户需要的额外服务。
两者的主要区别在于代理模式应用的情况是不改变接口命名的，而且是对已有接口功能的一种控制；而适配器模式则强调接口转换。

12.说明Observer模式的基本实现方式。如果不用该模式，要达到同样的效果，你会如何做？
观察者模式在关于目标角色、观察者角色通信的具体实现中，有两个版本。
一种情况便是目标角色在发生变化后，仅仅告诉观察者角色“我变化了”；观察者角色如果想要知道具体的变化细节，则就要自己从目标角色的接口中得到。这种模式被很形象的称为：拉模式——就是说变化的信息是观察者角色主动从目标角色中“拉”出来的。
还有一种方法，那就是我目标角色“服务一条龙”，通知你发生变化的同时，通过一个参数将变化的细节传递到观察者角色中去。这就是“推模式”——管你要不要，先给你啦。
这两种模式的使用，取决于系统设计时的需要。如果目标角色比较复杂，并且观察者角色进行更新时必须得到一些具体变化的信息，则“推模式”比较合适。如果目标角色比较简单，则“拉模式”就很合适。

如果不使用该模式，可采用策略模式，将不同的情况作为子类封装在一个类中,模拟observer模式中目标角色的不同状态，当外部状态发生变化时，可以选择不同的strategy1、strategy2…改变观察者角色，从而达到与观察者模式同样的效果。

13.请列举一个使用装饰模式的例子。画出你的例子的类图结构。
JUnit 中的装饰模式：在 JUnit 中，TestCase 是一个很重要的类，允许对其进行功能扩展。 在 junit.extensions 包中，TestDecorator、RepeatedTest 便是对 TestCase 的装饰模式扩展。下面我们将它们和上面的角色对号入座。

14.列举两个可以使我们在程序中不必使用if…else结构的软件设计模式。使用软件设计模式是如何做到这一点的？
策略模式（strategy）和状态模式（state）
策略模式是将不同算法（处理方法）封装到stategy类中，状态模式是将不同状态封装到state类中。二者都是通过，类中的子类，实现不同情况的调用，从而有效的替换充满在程序中的 if else 语句。

15.你认为在Linux平台上直接运行WIN32程序有可能吗？如认为不可能请说明理由；如认为可能应如何实现这一目标？
（1）两个OS内部实现有很大差别，甚至连路径的分隔符都不一样，一个WIN32程序无论如何到了最后也要调用Window api，而这些api在linux上根本没有实现（2）例如：就用户界面来说，有些windows的控件，在Linux上根本连对应的具有类似功能的控件都没有怎么执行？如果再涉及进程，线程就更复杂了，差距也更大，如果想用一个win32程序在linux上执行，必须有一个间接层来缓和二者差距，然后要求WIN32程序只能调用这个间接层里面的库函数

16. Java是一个跨平台的软件语言。为了实现跨平台，你认为采用哪种软件模式来实现跨平台部分更合理？说明你的理由。

答：abstract factory实现跨平台比较合适。用abstract factory提供一个高层接口，来建造每个所需的Product，当然具体的实现要用Concrete factory来实现，然后让每个os对应一个Concrete factory，这样当其它的Java类库需要平台支持时，只需调用abstract factory的相应函数即可，而无需关系它所在是什么平台。
例如：用户界面awt这个类体系,它是跨平台的，它本身不能有绘制图形界面的代码，因为这涉及具体的平台。所以它肯定要调用一个抽象工厂模式类的相应函数，具体实现就由concrete factory来负责。
Bridge模式可以分离接口及其实现部分，使接口部分和实现部分可以独立变化，同时可以对客户隐藏实现细节，实现bridge实现跨平台部分就有可能对不同的平台编写不同的具体实现，而同时又保持接口部分java语言可以独立变化。