体系结构复习题

1、简述三层架构开发模式及其优点。三层架构(3-tierapplication)通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合的思想。（1）表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。（2）业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。（3）数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。注：（内聚：一个模块内各个元素彼此结合的紧密程度；耦合：一个软件结构内不同模块之间互连程度的度量）优缺点优点：1、开发人员可以只关注整个结构中的其中某一层；2、可以很容易的用新的实现来替换原有层次的实现；3、可以降低层与层之间的依赖；4、有利于标准化；5、利于各层逻辑的复用。6、扩展性强。不同层负责不同的层面，如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)通过首先编写测试，可以迫使自己把程序设计为可测试的，迫使我们解除软件中的耦合（forceustodecouplethesoftware）(4)测试可以作为一种无价的文档形式，而且可以提供范例10、测试驱动开发遵循的3条简单的规则是什么？（1）除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。（2）只允许编写刚好能够导致失败的单元测试。（编译失败也属于一种失败）（3）只允许编写刚好能够导致一个单元测试失败的产品代码。11、XP中简单设计的概念及其指导原则。概念：•XP团队使他们的设计尽可能地简单、具有表现力（expressive）。此外，他们仅仅关注于计划在本次迭代中要完成的用户故事。他们不会考虑那些未来的用户故事。•XP要求用最简单的办法实现每个小需求，前提是按照这些简单设计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何画蛇添足的设计，而且所有这些设计都将在后续的开发过程中被不断地重整和优化。指导原则：(1)考虑能工作的最简单的事情尽量考虑最简单的方法实现当前的用户故事。(2)你不需要它将来会用到，现在不考虑，不得不用时再添加；(3)一次，并且只有一次极限编程者绝不能容忍重复的代码代码重复不仅仅是浪费存储空间，关键是“维护灾难消除重复最好的方法就是抽象。提炼出抽象，可以减少代码间的耦合。12、每个软件模块都应该具有的三项职责是什么？（1）它运行起来所完成的功能。这也是该模块得以完成的原因。（2）它要应对变化。几乎所有的模块在它们的生命周期中都要变化。开发者有责任保证这种改变应该尽可能地简单。（3）要和阅读它的人进行沟通。对该模块不熟悉的开发人员应该能够比较容易地阅读并理解它。13、简述常见的设计臭味。（1）僵化性僵化性是指难以对软件进行改动，即使简单的改动。如果单一的改动会导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。必须要改动的模块越多，设计就越僵化。–“它比我想象的要复杂的多！”（2）脆弱性脆弱性是指，在进行一个改动时，程序的许多地方就可能出现问题。常常是，出现新问题的地方与改动的地方并没有概念上的关联。要修正这些问题就会引出更多的问题，从而使开发团队就像一只不停追逐自己尾巴的狗一样忙得团团转。–随着脆弱性的增加，改动会引出意想不到的问题的可能性越来越大，“越修补越糟！”（3）牢固性–牢固性是指，设计中包含了对其他系统有用的部分，但是要把这些部分从系统中分离出来所需要的努力和风险是巨大的。这是一件令人遗憾的事，但是确实非常常见的事情。（4）粘滞性–粘滞性有两种表现形式：软件的粘滞性和环境的粘滞性。–当那些可以保持系统设计的方法比那些拼凑手法更难应用的时候，就表明设计具有高的粘滞性。（做错事容易，做正确的事情却很难）–当开发环境迟钝、低效时，就会产生环境的粘滞性。–无论项目具有哪种粘滞性，都很难保持项目中的软件设计。我们希望创建易于保持设计的系统和项目环境。（5）不必要的复杂性如果设计中包含有当前没有用的组成部分，它就包含不必要的复杂性。–为过多的可能性做准备，会使系统的结构变得混乱。（6）不必要的重复–剪切和粘贴也许是有用的文本编辑操作，但是它们却是灾难性的代码编辑操作。–当同样的代码以稍微不同的形式一再出现时，就表示开发人员忽视了抽象。对于他们来说，发现所有的重复并通过适当的抽象去消除它们的做法可能没有高的优先级别，但是这样做非常有助于使系统更加易于理解和维护。–重复代码会使系统改动变得异常困难。（7）晦涩性–是指模块难以理解。–为防止这种情况的发生，开发人员必须要站在代码阅读者的位置，共同努力对它们的代码进行重构，这样代码的阅读者就可以理解代码。可以被其他人进行评审。14、为什么说“源代码就是设计！”？软件项目的设计是一个抽象的概念，它和程序的概观、结构以及每一个模块、类和方法的详情和结构有关，可以使用许多不同的媒介描绘设计，但是最终的体现为源代码。15、简述单一职责原则。就一个类而言，应该仅有一个引起它变化的原因。每一个职责都是变化的一个轴线（anaxisofchange）。当需求变化时，该变化会反映为类的职责的变化，如果一个类承担了多余一个的职责，那么引起它变化的原因就会有多个。如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的（fragile）设计，当变化发生时，设计会遭受到意想不到的破坏。16、简述开放/封闭原则。对于扩展是开放的这意味着模块的行为是可扩展的。我们可以根据需求的变化来改变模块的功能对于修改是封闭的对模块行为进行扩展时，不必改动模块的源代码或二进制代码(需要重新编译即为修改)17、简述替代原则。子类型(subtype)必须能够替换掉它们的基类型(basetype)。•只有子类能完全替代父类才能保证抽象父类的复用和扩展。•只要是基类出现的地方，一定能够出现子类！•LSP指导继承，是继承的基石18、简述依赖倒置原则。•高层模块不应该依赖于低层模块，二者都应该依赖于抽象。•抽象不应该依赖于细节，细节应该依赖于抽象。•推论：要针对接口编程，不要针对实现编程。19、简述接口隔离原则这个原则用来处理“胖接口”所存在的缺点—如果类的接口不是内聚的，就表示该类具有“胖接口”。“胖接口”应该分解，随之而来的是类的分解，客户看到的应该是多个具有内聚接口的抽象类。20、简述迪米特法则。迪米特法则（LawofDemeter，简写LoD）又叫作最少知识原则（LeastKnowledgePrinciple简写LKP），就是说一个对象应当对其他对象有尽可能少的了解。不要跟“陌生人”说话；只与你直接的朋友们通信；每一个软件单位对其它的单位都只有最少的知识，而且仅局限于那些与本单位密切相关的软件单位。21、简述合成/聚合复用原则。合成表示一种强的拥有关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样；聚合表示一种弱的拥有关系，体现的是A对象可以包含B对象，但是B对象并不是A对象的一部分22、简述什么是设计模式。每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。--经验性的好的方案面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。23、什么是面向对象的三大机制-封装，隐藏内部实现–继承，复用现有代码，扩展已有的行为–多态，改写已有的行为24、试给出多线程环境中单件模式的实现。通过lock建立临界区，以保证多线程访问安全。通过Double-Check?Locking（双重检测）来保证多线程访问的效率。volatile修饰：编译器在编译代码的时候会对代码的顺序进行微调，用volatile修饰保证了严格意义的顺序。一个定义为volatile的变量是说这变量可能会被意想不到地改变，这样，编译器就不会去假设这个变量的值了。精确地说就是，优化器在用到这个变量时必须每次都小心地重新读取这个变量的值，而不是使用保存在寄存器里的备份。25、简述简单工厂