2024年4月19日发(作者：)

一、选择题

CDABC DABCC ACDCC BADCA DDCBC ADBDA

二、判断题

√√

X

√√ √√

X X

√

X

√√√

X X

X X X

√√

X

√

X X X

三、简答题

1、 简述实体类的概念及其作用。

实体类实现所谓的对象关系映射（Object Relational Mapping，简称ORM），是

为了解决面向对象的类与关系数据库的表之间，存在的不匹配的现象，通过使

用描述对象和关系之间映射的元数据，在程序中的类对象，与关系数据库的表

之间建立持久的关系，用于在程序中描述数据库表。本质上就是将数据从一种

形式转换到另外一种形式。

简单地说，就是描述一个业务实体的类。实体类对象是现实世界中实体对象在

计算机中的表示，在层与层之间以及层内模块间进行数据传输。

2、敏捷开发宣言。

我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法，通过这

项工作，我们认为：

个体和交互 胜过 过程和工具

可以工作的软件 胜过 面面俱到的文档

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

虽然右项也有其价值，但我们认为左项更加重要。

3、 简述XP的短交付周期的概念。

迭代计划: XP项目每两周交付一次可以工作的软件。每两周的迭代都实现了利

益相关者的一些需求，在每次迭代结束时，会给利益相关者演示迭代生成的系

统，以得到他们的反馈。迭代是一次较小的交付，可能会被加入到产品中，也

可能不会。每个周期（Iteration）开发的需求都是用户最需要的东西。

发布计划：XP团队通常会创建一个计划来规划随后大约6次迭代的内容。一次

发布通常需要2-3个月的工作。它表示了一次较大的交付，通常此次交付会被

加入到产品中。发布计划不是一成不变的，客户可以随时改变计划的内容，他

可以取消用户故事，编写新的用户故事，或者改变用户故事的优先级别。但是

客户应该更改后面迭代的内容，尽量不要更改下一次迭代。

4、 测试驱动开发的概念及其积极作用。

编写所有产品代码的目的都是为了使失败的单元测试能够通过。首先编写一个

单元测试，由于它要测试的功能还不存在，因此它会运行失败，然后，编写代

码使测试通过。编写测试用例和代码之间的更迭速度是很快的，基本上在几分

钟左右。

积极的影响：

(1) 程序中的每一项功能都有测试来验证它的操作的正确性。

(2) 首先编写测试可以迫使我们使用不同的观察点---程序调用者的角度，

可以设计出便于调用的软件

(3) 通过首先编写测试，可以迫使自己把程序设计为可测试的，迫使我们

解除软件中的耦合（force us to decouple the software）

(4) 测试可以作为一种无价的文档形式，而且可以提供范例

5、XP中简单设计的概念及其指导原则。

XP团队使他们的设计尽可能地简单、具有表现力（expressive）。此外，他们仅

仅关注于计划在本次迭代中要完成的用户故事。他们不会考虑那些未来的用户

故事。

XP要求用最简单的办法实现每个小需求，前提是按照这些简单设计开发出

来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以

了，不需要任何画蛇添足的设计，而且所有这些设计都将在后续的开发过程中

被不断地重整和优化。

3条XP指导原则：

(1) 考虑能工作的最简单的事情

尽量考虑最简单的方法实现当前的用户故事。

(2) 你不需要它

将来会用到，现在不考虑，不得不用时再添加；

(3) 一次，并且只有一次

极限编程者绝不能容忍重复的代码

6、简述常见的设计臭味。

僵化性是指难以对软件进行改动，即使简单的改动；脆弱性是指，在进行一个

改动时，程序的许多地方就可能出现问题；牢固性是指，设计中包含了对其他

系统有用的部分，但是要把这些部分从系统中分离出来所需要的努力和风险是

巨大的；软件的粘滞性和环境的粘滞性：当那些可以保持系统设计的方法比那

些拼凑手法更难应用的时候，就表明设计具有高的粘滞性，当开发环境迟钝、

低效时，就会产生环境的粘滞性；如果设计中包含有当前没有用的组成部分，

它就包含不必要的复杂性；不必要的重复， 剪切和粘贴也许是有用的文本编辑

操作，但是它们却是灾难性的代码编辑操作；晦涩性是指模块难以理解。

7、 简述开放/封闭原则。

开放-封闭原则：软件实体（类、模块、函数等）应该是可以扩展的，但是不可

修改。

（1）对于扩展是开放的--这意味着模块的行为是可扩展的。我们可以根据需求

的变化来改变模块的功能

（2）对于修改是封闭的--对模块行为进行扩展时，不必改动模块的源代码或二

进制代码(需要重新编译即为修改)

把一个功能的通用部分和实现细节清晰的分离开来；通过派生来扩展功能。

8、 简述什么是设计模式。

每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方

案的核心。

设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。--经验

性的好的方案

面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的

对象之间常见的组织关系。

9、试给出抽象工厂模式的结构图及其角色描述。

所谓的抽象工厂是指一个工厂等级结构

可以创建出分属于不同产品等级结构的

一个产品族中的所有对象。

抽象工厂（Abstract Factory）角色：担

任这个角色的是工厂方法模式的核心，

它是与应用系统商业逻辑无关的(给出

创建对象的几个方法的说明)。

具体工厂（Concrete Factory）角色：这

个角色直接在客户端的调用下创建多个

具体产品的实例。这个角色含有选择合

适的产品对象的逻辑，而这个逻辑是与

应用系统的商业逻辑紧密相关的(实现

具体的创建方法)。

抽象产品（Abstract Product）角色：担

任这个角色的类是工厂方法模式所创建

的具体对象的父类，或它们共同拥有的

接口—给出产品对象业务上的共同点。

具体产品（Concrete Product）角色：抽象工厂模式所创建的任何产品对象都是

某一个具体产品类的实例。这是客户端最终需要的东西，其内部一定充满了应

用系统的商业逻辑。

10、简述观察者模式的

结构。

定义对象间的一种一对

多的依赖关系，以便当

一个对象的状态发生改

变时，所有依赖于它的

对象都得到通知并自动

更新。

抽象主题（Subject）角

色：抽象主题角色把所

有对观察考对象的引用

保存在一个聚集里，每

个主题都可以有任何数

量的观察者。抽象主题

提供一个接口，可以增

加和删除观察者对象，

主题角色又叫做抽象被观察者（Observable）角色，一般用一个抽象类或者一个

接口实现。

抽象观察者（Observer）角色：为所有的具体观察者定义一个接口，在得到主

题的通知时更新自己。这个接口叫做更新接口。抽象观察者角色一般用一个抽

象类或者一个接口实现。在这个示意性的实现中，更新接口只包含一个方法

（即Update()方法），这个方法叫做更新方法。

具体主题（ConcreteSubject）角色：将有关状态存入具体现察者对象；在具体

主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色又叫

做具体被观察者角色（Concrete Observable）。具体主题角色通常用一个具体子

类实现。

具体观察者（ConcreteObserver）角色：存储与主题的状态自恰的状态。具体现

察者角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的

状态相协调。如果需要，具体现察者角色可以保存一个指向具体主题对象的引

用。具体观察者角色通常用一个具体子类实现。

11、软件体系结构的概念及构成。

答案: 软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理

构件、数据构件和连接构件。处理构件负责对数据进行加工；数据构件是被加

工的信息；连接构件把体系结构的不同部分组合连接起来。

12、什么是结对编程？

答案: 所有产品（production）代码都是由结对的程序员使用同一台电脑共同完

成的，结对人员中的一位控制键盘并输入代码，另一位观察输入的代码并寻找

着代码中的错误和可以改进的地方。两人频繁互换角色，结对的关系每天至少

改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作， “业务

领域专家”也需要与团队中的其他所有成员结对。

13、测试驱动开发遵循的3条简单的规则是什么？

答案: 除非已经编写了一个不能通过的单元测试，否则不编写任何产品代码；

只要编写能够正好导致测试不通过或者编译失败的单元测试就够了，无需再

多；

只要编写能够正好使失败的单元测试通过的产品代码就够了，无需再多。

遵循上述原则，以非常短的周期（1-2分钟）迭代；

14、简述适配器模式的定义及对象适配器的结构。

答案: 将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由

于接口不兼容而不能一起工作的那些类可以一起工作。

15、简述三层架构开发模式及其优点。

微软推荐的三层结构通常是指数据访问层（DAL）、业务逻辑层（BLL）和表示

层（UI）。

与网络协议的分层一样，软件设计也要进行分层，分层的目的是为了实现“高

内聚、低耦合”，采用“分而治之”的思想，把任务划分成子任务，逐个解决，

易于控制，易于延展，易于多人进行项目合作。

优点：

不必为了业务逻辑上的微小变化而导至整个程序的修改，只需要修改商业逻辑

层中的一个函数或一个过程—灵活，适应多变的需求；增强了代码的可重用

性；便于不同层次的开发人员之间的合作，只要遵循一定的接口标准就可以进

行并行开发了，最终只要将各个部分拼接到一起构成最终的应用程序。

16、每个软件模块都应该具有的三项职责是什么？

它运行起来所完成的功能，这也是该模块得以完成的原因。

它要应对变化，几乎所有的模块在它们的生命周期中都要变化。开发者有责任

保证这种改变应该尽可能地简单。

它要和阅读它的人进行沟通。对该模块不熟悉的开发人员应该能够比较容易地

阅读并理解它。

17、为什么说“源代码就是设计！”？

软件项目的设计是一个抽象的概念，它和程序的概观、结构以及每一个模块、

类和方法的详情和结构有关，可以使用许多不同的媒介描绘设计，但是最终的

体现为源代码。

Reeves认为：

软件系统的源代码是它的主要设计文档。

用来描绘源代码的图示只是设计的附属物而不是设计本身。

从根本上讲，源代码就是设计！

18、简述单一职责原则。

就一个类而言，应该仅有一个引起它变化的原因。

在SRP中，我们把职责定义为“变化的原因”（a reason for change）。

软件设计真正要做的许多内容，就是发现职责并把那些职责互相分离(找到变化

点,并封装之)。事实上，我们将要论述的其余原则都会以这样或那样的方式回到

这个问题上。

19、简述依赖倒置原则。

高层模块不应该依赖于低层模块，二者都应该依赖于抽象。

抽象不应该依赖于细节，细节应该依赖于抽象。

要针对接口编程，不要针对实现编程。

20、什么是面向对象的三大机制？

各种面向对象编程语言相互有别，但都能看到它们对面向对象三大机制的支

持，即：“封装、继承、多态”

封装，隐藏内部实现

继承，复用现有代码，扩展已有的行为

多态，改写已有的行为

21、简述简单工厂模式的优缺点。

优点：

工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，

客户端可以免除直接创建产品对象的责任，而仅仅"消费"产品。简单工厂模式

通过这种做法实现了对责任的分割。

缺点：

当产品有复杂的多层等级结构时，工厂类只有自己，以不变应万变，就是模式

的缺点。因为工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统

都要受到影响。

违反开放/封闭原则: 系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，

有可能造成工厂逻辑过于复杂。

另外，简单工厂模式通常使用静态工厂方法，这使得无法由子类继承，造成工

厂角色无法形成基于继承的等级结构。

22.简述XP中的完整团队概念。

答案:客户、管理者和开发人员应该紧密地工作在一起，以便彼此知晓对方所面

临的问题，并共同去解决这些问题。XP团队中的客户是指定义产品的特性并排

列这些特性优先级的人或者团体。最好的情况是客户和开发人员在同一个房间

中工作，次一点的情况是客户和开发人员之间的距离在100米内。如果确实无

法和客户在一起工作，那么就去寻找能够在一起工作、愿意并能够代替真正客

户的人。

四、设计题

1、试给出多线程安全的“懒汉式”和“饿汉式”单件模式的代码。

public class Singleton //懒汉式

{

//唯一的实例对象,每次访问时重新读取instance变量的值

private static volatile Singleton instance = null;

private static readonly object lockHelper = new object();//辅助加锁对象

private Singleton() //私有构造函数，防止外部应用使用new方法创建新

的实例

{

}

public static Singleton GetInstance() //获取唯一的实例对象

{

if (instance == null) //先判断对象是否存在--这样做能够保证执行效

率！

{

lock (lockHelper) //加锁--创建临界区

{

if (instance == null) //加锁后二次判断，只允许一个线程

判断

{

instance = new Singleton();

}

}

}

return instance;

}

}

public class Singleton //饿汉式

{

//公共静态只读属性--依靠系统在加载时进行初始化，对于多线程环境

也是安全的

public static readonly Singleton instance = new Singleton();

private Singleton() //私有构造函数，防止外部应用使用new方法创建

新的实例

{}

}

2、设计一个命令行状态下运行的运算程序，目前支持加减乘除（+，-，*，/）

等四则运算，将来还可能添加求余数(%)运算，请以学过的设计模式设计一个

程序结构，先画出类图,再写出代码。

要求： （1）符合开放/封闭原则；

（2）业务逻辑和界面逻辑必须分开；

（3）先设计只支持四则运算的程序，再说明如何升级程序加上求余数

（%）运算。

类图：

代码：

:

///

/// 抽象的运算基类

///

public class Operation

{

//二个运算对象

private double _numberA;

private double _numberB;

///

/// 运算数A

///

public double NumberA

{

get { return _numberA; }

set { _numberA = value; }

}

///

/// 运算数B

///

public double NumberB

{

get { return _numberB; }

set { _numberB = value; }

}

//获取运算结果，此处为虚方法，子类必须重写

public virtual double GetResult()

{

double result=0;

return result;

}

}

:

///

/// 加法类，派生自运算类，在GetResult方法中具体实现加法运算

///

public class OperationAdd : Operation

{

public override double GetResult() //实现具体的加法运算

{

double result = 0;

result = NumberA + NumberB;

return result;

}

}

与上面的OperationAdd类似有OperationSub、OperationMul和OperationDiv

：

///

/// 运算对象工厂类

///

public class OperationFactory

{

public static Operation CreateOperate(string operate) //根据传进来的运算

符来决定创建什么样的对象

{

return (Operation) ("程序集名称").CreateInstance(转

换运算符为类名称(operate));

}