体系结构复习题Word下载.docx
《体系结构复习题Word下载.docx》由会员分享，可在线阅读，更多相关《体系结构复习题Word下载.docx（14页珍藏版）》请在冰点文库上搜索。
不同层负责不同的层面，如PetShop可经过简单的配置实现Sqlserver和oracle之间的转换，当然写好了也可以实现B/S与C/S之间的转换
7、安全性高。
用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。
8、项目结构更清楚，分工更明确，有利于后期的维护和升级
缺点：
1、降低了系统的性能。
这是不言而喻的。
如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。
这种修改尤其体现在自上而下的方向。
如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码
3、增加了代码量，增加了工作量
2、实体类的概念及其作用。
实体类，主要是作为数据管理和业务逻辑处理层面上存在的类别。
它的主要职业是存储和管理系统内部的信息，它可以在抽象类的基础上进一步定义具体的类。
3、敏捷开发宣言。
1、个体和交互胜过过程和工具
2、可工作的软件胜过面面俱到的文档
3、客户协助胜过合同谈判
4、响应变化胜过遵循计划
4、敏捷开发为什么说客户合作胜过合同谈判？
不能像订购日用品一样订购软件！
完全放开的方法也行不通：
仅告诉团队想要的东西，然后期望团队消失一段时间回来后就能交付一个令人满意的产品？
成功的项目需要定期且频繁的客户反馈
为开发团队和客户的协同方式提供指导的合同才是最好的合同，而不是试图去规定项目范围的细节和固定成本下的进度。
项目的需求基本处于一个持续变化的状态，大的变更是很平常的，成功的关键在于与客户的紧密协作。
5、简述XP中的完整团队概念
我们希望客户、管理者和开发人员紧密地工作在一起，以便彼此知晓对方所面临的问题，并共同去解决这些问题。
XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。
最好的情况是客户和开发人员在同一个房间中工作，次一点的情况是客户和开发人员之间的距离在100米内。
如果确实无法和客户在一起工作，那么就去寻找能够在一起工作、愿意并能够代替真正客户的人。
6、简述XP的短交付周期的概念。
XP项目每两周交付一次可以工作的软件。
每两周的迭代都实现了利益相关者的一些需求，在每次迭代结束时，会给利益相关者演示迭代生成的系统，以得到他们的反馈
7、什么是用户故事？
就是正在进行的关于需求谈话的助记符。
它是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的实践
8、什么是结对编程？
所有产品（production）代码都是由结对的程序员使用同一台电脑共同完成的。
结对人员中的一位控制键盘并输入代码，另一位观察输入的代码并寻找着代码中的错误和可以改进的地方。
两人频繁互换角色,结对编程的代码是由两人共同设计、共同编写的，两人功劳均等。
结对的关系每天至少改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。
在一个迭代期间，每个团队成员应该和所有其他的团队成员在一起工作过，并且他们应该参与了本次迭代中所涉及的每项工作。
这样可以促进知识在团队中的传播
“业务领域专家”也需要与团队中的其他所有成员结对
9、测试驱动开发的概念及其积极作用。
概念：
•
它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代
码，通过测试来推动整个开发的进行。
这有助于编写简洁可用和高质量的代码，并加速开发过程。
编写所有产品代码的目的都是为了使失败的单元测试能够通过。
首先编写一个单元测
试，由于它要测试的功能还不存在，因此它会运行失败，然后，编写代码使测试通过。
这样一种方式所编写的代码天生就是可测试的，并可以激发程序员去解除各个模块之间
的耦合，这样才能够独立地对它们进行测试。
面向对象设计的原则在进行这种解除耦合方面具有巨大的帮助作用。
积极作用：
（1）
程序中的每一项功能都有测试来验证它的操作的正确性。
（2）
首先编写测试可以迫使我们使用不同的观察点---程序调用者的角度，可以设计出便于调用的软件
（3）
通过首先编写测试，可以迫使自己把程序设计为可测试的，迫使我们解除软件中的耦合（force
us
to
decouple
the
software）
（4）
测试可以作为一种无价的文档形式，而且可以提供范例
10、测试驱动开发遵循的3条简单的规则是什么？
（1）除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。
（2）只允许编写刚好能够导致失败的单元测试。
（编译失败也属于一种失败）
（3）只允许编写刚好能够导致一个单元测试失败的产品代码。
11、XP中简单设计的概念及其指导原则。
XP团队使他们的设计尽可能地简单、具有表现力（expressive）。
此外，他们仅仅关注于
计划在本次迭代中要完成的用户故事。
他们不会考虑那些未来的用户故事。
XP要求用最简单的办法实现每个小需求，前提是按照这些简单设计开发出来的软件必
须通过测试。
这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何画蛇添足的设计，而且所有这些设计都将在后续的开发过程中被不断地重整和优化。
指导原则：
考虑能工作的最简单的事情尽量考虑最简单的方法实现当前的用户故事。
你不需要它将来会用到，现在不考虑，不得不用时再添加；
一次，并且只有一次极限编程者绝不能容忍重复的代码代码重复不仅仅是浪费存储空间，关键是“维护灾难消除重复最好的方法就是抽象。
提炼出抽象，可以减少代码间的耦合。
12、每个软件模块都应该具有的三项职责是什么？
（1）它运行起来所完成的功能。
这也是该模块得以完成的原因。
（2）它要应对变化。
几乎所有的模块在它们的生命周期中都要变化。
开发者有责任保证这种改变应该尽可能地简单。
（3）要和阅读它的人进行沟通。
对该模块不熟悉的开发人员应该能够比较容易地阅读并理解它。
13、简述常见的设计臭味。
（1）僵化性
僵化性是指难以对软件进行改动，即使简单的改动。
如果单一的改动会导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。
必须要改动的模块越多，设计就越僵化。
–
“它比我想象的要复杂的多！
”
（2）脆弱性
脆弱性是指，在进行一个改动时，程序的许多地方就可能出现问题。
常常是，出现新问题的地方与改动的地方并没有概念上的关联。
要修正这些问题就会引出更多的问题，从而使开发团队就像一只不停追逐自己尾巴的狗一样忙得团团转。
随着脆弱性的增加，改动会引出意想不到的问题的可能性越来越大，“越
修补越糟！
（3）牢固性
牢固性是指，设计中包含了对其他系统有用的部分，但是要把这些部分从系
统中分离出来所需要的努力和风险是巨大的。
这是一件令人遗憾的事，但是确实非常常见的事情。
（4）粘滞性
粘滞性有两种表现形式：
软件的粘滞性和环境的粘滞性。
当那些可以保持系统设计的方法比那些拼凑手法更难应用的时候，就表明设
计具有高的粘滞性。
（做错事容易，做正确的事情却很难）
当开发环境迟钝、低效时，就会产生环境的粘滞性。
无论项目具有哪种粘滞性，都很难保持项目中的软件设计。
我们希望创建易
于保持设计的系统和项目环境。
（5）不必要的复杂性
如果设计中包含有当前没有用的组成部分，它就包含不必要的复杂性。
为过多的可能性做准备，会使系统的结构变得混乱。
（6）不必要的重复
剪切和粘贴也许是有用的文本编辑操作，但是它们却是灾难性的代码编辑
操作。
当同样的代码以稍微不同的形式一再出现时，就表示开发人员忽视了抽象。
对于他们来说，发现所有的重复并通过适当的抽象去消除它们的做法可能没有高的优先级别，但是这样做非常有助于使系统更加易于理解和维护。
重复代码会使系统改动变得异常困难。
（7）晦涩性
是指模块难以理解。
为防止这种情况的发生，开发人员必须要站在代码阅读者的位置，共同努力
对它们的代码进行重构，这样代码的阅读者就可以理解代码。
可以被其他人进行评审。
14、为什么说“源代码就是设计！
”？
软件项目的设计是一个抽象的概念，它和程序的概观、结构以及每一个模块、类和方法的详情和结构有关，可以使用许多不同的媒介描绘设计，但是最终的体现为源代码。
15、简述单一职责原则。
就一个类而言，应该仅有一个引起它变化的原因。
每一个职责都是变化的一个轴线（an
axis
of
change）。
当需求变化时，该变化会反映为
类的职责的变化，如果一个类承担了多余一个的职责，那么引起它变化的原因就会有多个。
如果一个类承担的职责过多，就等于把这些职责耦合在了一起。
一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。
这种耦合会导致脆弱的（fragile）设计，当变化发生时，设计会遭受到意想不到的破坏。
16、简述开放/封闭原则。
对于扩展是开放的
这意味着模块的行为是可扩展的。
我们可以根据需求的变化来改变模块的功能
对于修改是封闭的
对模块行为进行扩展时，不必改动模块的源代码或二进制代码（需要重新编译即为修改）
17、简述替代原则。
子类型（subtype）必须能够替换掉它们的基类型（base
type）。
只有子类能完全替代父类才能保证抽象父类的复用和扩展。
只要是基类出现的地方，一定能够出现子类！
LSP指导继承，是继承的基石
18、简述依赖倒置原则。
高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
推论：
要针对接口编程，不要针对实现编程。
19、简述接口隔离原则
这个原则用来处理“胖接口”所存在的缺点—如果类的接口不是内聚的，就表示该类具有“胖接口”。
“胖接口”应该分解，随之而来的是类的分解，客户看到的应该是多个具有内聚接口的抽象类。
20、简述迪米特法则。
迪米特法则（LawofDemeter，简写LoD）又叫作最少知识原则（LeastKnowledgePrinciple简写LKP），就是说一个对象应当对其他对象有尽可能少的了解。
不要跟“陌生人”说话；
只与你直接的朋友们通信；
每一个软件单位对其它的单位都只有最少的知识，而且仅局限于那些与本单位密切相关的软件单位。
21、简述合成/聚合复用原则。
合成表示一种强的拥有关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样；
聚合表示一种弱的拥有关系，体现的是A对象可以包含B对象，但是B对象并不是A对象的一部分
22、简述什么是设计模式。
每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。
设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。
--经验性的好的方案面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。
23、什么是面向对象的三大机制
-封装，隐藏内部实现
–继承，复用现有代码，扩展已有的行为
–多态，改写已有的行为
24、试给出多线程环境中单件模式的实现。
通过lock建立临界区，以保证多线程访问安全。
通过Double-Check?
Locking（双重检测）来保证多线程访问的效率。
volatile修饰：
编译器在编译代码的时候会对代码的顺序进行微调，用volatile修饰保证
了严格意义的顺序。
一个定义为volatile的变量是说这变量可能会被意想不到地改变，这样，编译器就不会去假设这个变量的值了。
精确地说就是，优化器在用到这个变量时必须每次都小心地重新读取这个变量的值，而不是使用保存在寄存器里的备份。
25、简述简单工厂模式的优缺点。
优点：
–工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实
例，客户端可以免除直接创建产品对象的责任，而仅仅"
消费"
产品。
简单工厂模式通过这种做法实现了对责任的分割。
缺点
–当产品有复杂的多层等级结构时，工厂类只有自己，以不变应万变，就是模
式的缺点。
因为工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。
–违反开放/封闭原则:
系统扩展困难，一旦添加新产品就不得不修改工厂逻
辑，有可能造成工厂逻辑过于复杂。
–另外，简单工厂模式通常使用静态工厂方法，这使得无法由子类继承，造成
工厂角色无法形成基于继承的等级结构。
26试给出抽象工厂模式的结构图及其角色描述
27简述适配器模式的结构
将一个类的接口转换成客户希望的另一个接口。
Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
28简述桥接模式的结构
29简述组合模式的概念及其分类
30试区分代理模式和适配器模式的不同之处
31简述命令模式的定义与结构
在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。
但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。
在这种情况下，如何将“行为请求者”与“行为实现者”解耦？
将一组行为抽象为对象，实现二者之间的松耦合。
这就是命令模式（CommandPattern）。
32简述观察者模式的定义与结构
33简述观察者模式的优缺点、
（1）观察者模式可以实现表示层和数据逻辑层的分离，定义了稳定的消息更新消息传递更新机制，并抽象了更新接口，使得可以有各种各样不同的表示层充当具体观察者角色。
（2）在观察目标和观察者之间建立一个抽象的耦合，观察目标只需要维持一个抽象观察者的集合，必须了解其具体观察者。
由于观察目标和观察者没有紧密的耦合在一起，因此它们属于不同的抽象化层次。
（3）观察者模式支持广播通信，观察目标会向所有已注册的观察者对象发送通知，简化了一个多系统设计的难度。
（4）观察者模式符合开闭原则，增加新的具体观察者无须修改原有代码，再具体观察者与观察者目标之间不存在关联关系的情况下增加新的观察目标也很方便。
缺点：
–如果一个被观察者对象（目标对象Subject）有很多直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
–如果在被观察者之间有循环依赖的话，被观察者会触发它们之间进行循环调用，导致系统崩溃。
在使用观察考模式时要特别注意这一点。
–虽然观察者模式可以随时使观察者知道所观察的对象发生了变化，但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。
升级会员 