组合（Composite）模式：
|
| threehair 回复于：2003-08-27 08:42:39
|
敏捷思维－架构设计中的方法学(7)
组合使用模式
--------------------------------------------------------------------------------
来自：IBM China 作者：林星 [2003/04/17]
我们已经讨论了敏捷架构设计的4种过程模式，在这一章中，我们对这四种过程模式做一个小结，并讨论4者间的关系以及体现在模式中的敏捷方法论特色。通过这一章的描述，大家能够对前面的内容有更进一步的了解。
四种模式的着重点
我把源自需求、团队设计、简单设计、迭代设计这4种过程模式归类为架构设计的第一层次，这4种模式能够确定架构设计过程的框架。这里需要对框架的含义进行澄清：架构设计的框架并不是说你要严格的按照文中介绍的内容来进行架构设计，在文章的一开始我们就指出，模式能够激发思考。因此，这一框架是需要结合实际，进行改造的。实际，我们在这一个部分中介绍的，比较偏向于原则，我们花了很大的时间来讨论原则的来龙去脉，而原则的度，则要大家自己去把握。为什么我们不讨论原则的度呢？这里有两个原因，一个是软件开发团队各有特色，很难定义出一个通用的度。第二个原因是我的水平不够，实践经验也不够丰富。
前面提到的四种模式其实是从四个侧面讨论了架构设计中的方法问题。源自需求提供了架构设计的基础。在软件过程中，架构设计是承接于需求分析的，如果没有良好的需求分析活动的支持，再好的架构设计也没有用。因此我们把这一模式放在首位，做为架构设计的目标。
有了确定的目标，还需有组织的保证，这也就是第二种模式――团队设计的由来。敏捷方法提倡优秀的沟通，因此团队设计是必要且有效的。而团队设计的另一个意图，是保证架构设计的下游活动得以顺利的进行，例如详细设计、编码、测试等。由于开发团队中的人大都加入了架构设计，因此最大程度的减小了不同的活动间的信息损耗和沟通效率低下的问题。如果说源自需求模式是起承上的作用，那么团队设计模式则是扮演了启下的角色。
在软件设计的过程中，沟通往往扮演着非常重要的角色。从团队设计开始的几种模式所要解决的都是沟通的问题。团队设计对沟通的贡献在于它能够把设计意图以最小的代价传播到开发团队的每个角落。这样，设计和下游的活动间由于沟通不畅产生的问题就能够得到缓解。一般而言，设计到编码会经历一个信息损失的过程，编码人员无法正确理解设计人员的意图，设计人员却往往无法考虑到一些编码的细节。虽然我们可以通过共通的设计符号来提高沟通的质量，例如UML。但是实践证明，只要能够保证畅通的沟通，即便没有优秀的开发方法，项目成功的概率依然很高。因此对于单个的项目来说，最关键的问题还是在于沟通。只要组织得当，团队设计是一个值得应用的模式。当然，配合以UML为代表的建模语言，更能够提高沟通的效果。
在设计中，我们发现，当设计信息转换为编码信息需要一定的时间，这个时间包括设计的组织时间，设计被理解的时间。如果设计比较复杂，或者说设计的文档比较复杂，编码人员花在理解上的时间就会大大增加。因此，权衡后的结果是，相对于详细的设计说明书而言，简单的设计说明书再配合一定程度的面对面沟通能够起到更好的效果。"简单要比复杂有效"，这就是简单设计模式的基本思路。
同样，简单的思路还会用在软件开发的各个方面，例如文档、设计、流程。坚持简单的原则，并不断的加以改进，是降低软件开发成本的一种很有效的做法。
在有了以上的思路之后，我们还需要面对两个现实的问题。需求的变化将会导致设计的不稳定，而需求的复杂性又会导致简单架构设计的困难。为了解决这个问题，我们引入了迭代的方法，将问题分割为多个子问题（把一个复杂的问题分解为多个较简单的子问题是计算机领域最常见的处理方法）。这样，问题的范围和难度都大大降低了。而更关键的是，由于对用户需求理解不充分或用户表达需求有错导致的设计风险被降到最低点。迭代和前面几个模式都有关系。
需求和迭代
源自需求模式是架构设计中的起手式，没有这一模式的支持，架构设计只能是空中楼阁。其实，源自需求模式严格意义上并不能算是敏捷方法论的特色，而应该算是软件开发的天然特性。不幸的是，就是这么一个基本的原则，却没能够引起开发者足够的重视。
敏捷方法论中把需求摆在一个非常重要的位置，我们把源自需求模式作为架构设计的第一个模式，主要的目的是承接架构设计的上游工作――需求。需求决定架构，因此，我们在经典的瀑布模型中可以看到需求到设计的严格的分界线，但是在实际的开发中，按照瀑布模型的理论往往会遇到很多的问题，所以，我们尝试着把需求和（架构）设计之间的界限打破，形成一个重叠的地带，从而提高软件开发的速度。因此，我们在源自需求模型中指出，架构设计是紧随着需求开始的。
需求对软件开发最具影响就是需求的不稳定性。我们都非常的清楚软件开发的曲线，越到软件开发的后期，修改软件的成本越高。因此，在软件开发上游的需求的变动将会对软件开发的下游产生天翻地覆的影响。为了协调这一矛盾，软工理论提出了螺旋开发模型，这就是我们在迭代开发模式中的讨论的理论基础。把软件开发过程分为多个的迭代周期，每一次的迭代周期最后都将生成一个可交付的软件，用户在每一次的迭代结束后，可以试用软件，提出下一步的需求或是改变原先的需求。通过这样的方式，把客户、开发商的风险降到一个可以接受的水平上。
请注意迭代的前提：需求的易变性。因此，对于那些需求容易发生变化的项目，我们就可以使用迭代式的开发过程，虽然我们会付出一些额外的成本（刚开始这个成本会比较大，但可以用较长的迭代周期来降低这种成本），但是风险减小了。而对于需求比较固定的项目，是不是有必要使用迭代的方法，就要看具体的环境了。因此，我们是根据实际的情况选用开发方法，而不是因为先进或是流行的原因。
实际上，由于现代社会的特性，大部分的项目都是可以采用迭代方法。因此，我们的选择就变成了了迭代周期应该要多长。迭代周期在理论上应该是越短越好，但是并没有一个绝对的数值，时间的跨度一般从几周到几个月。一般来说，迭代周期会受到几个因素的影响：
各模块的关联程度。在软件开发中，我们有时候很难把一些模块分离开来，要开发模块A，就需要模块B，而模块B又需要模块C。各模块的关联程度越高，迭代周期越长。当然，也相应的解决方法，我们可以在各模块的功能中选取出一些关键点，作为里程碑，以里程碑作为迭代完成点。
人员技能、经验的平均程度。团队中成员的开发能力、开发经验良莠不齐，这也是造成迭代周期延长的一个原因。能力低、经验少的开发人员会拖后每一次迭代的时间。针对这种情况，做好统筹规划就显得非常的重要，可以通过一两次的迭代，找出队伍中的瓶颈人员，安排相应的对策。
工具的缺乏。迭代周期越短，就意味着build、发布的次数越多，客户也就有更多的机会来修改需求。这要求有相关的工具来帮助开发人员控制软件。最重要的工具是回归测试工具。每一次迭代都需要增加新的功能，或是对原先的功能进行改动，这就有可能引入新的bug，如果没有回归测试，开发人员就需要花费时间重新测试原先的功能。
计划、控制的能力。迭代周期越短，所需要的计划、控制的能力就越强。因为短时间内的计划制定和实施需要高度的细分，这就要求开发团队的管理者对开发能力、工作量、任务分配有很强的认识，才能做好这项工作。不过，迭代周期越短，同样开发时间的迭代次数就越多，而团队调整、改进计划控制的机会就越多。因此，后期的迭代一般都能够做到比较精确的控制。而这样的做法，要比问题堆积到软件交付日才爆发出来要好的多。没有突然落后的软件，只有每天都在落后的软件。
简单和迭代
简单和迭代关系是双向的。
在现实设计我们很难界定出简单设计的程度。怎样的架构设计才算是简单？按照我们在简单设计模式中的讨论，刚好满足目前的需求的架构设计就算是简单的设计。但是，从另外一个方面考虑，需求的易变性限制我们做出简单的设计，因为我们不能够肯定目前的需求将来会发生什么样的变化。因此，为了克服对未知的恐惧，我们花了很大的力气设计一些灵活的、能够适应变化的架构。这是源自需求模式对简单设计模式的影响。
源自需求和迭代设计的关系的讨论建议我们把需求分为多个迭代周期来实现。那么，相应的架构设计也被分在多个迭代周期中。这样的方法可以降低架构设计的复杂程度。因为设计人员不需要考虑软件的全部需求，而只需要考虑当前迭代周期的需求。复杂性的降低将会有助于架构设计的简单化，从而达到简单设计的一系列的好处（参见简单设计）。
我们从迭代设计中的最后一个例子可以清楚的看到迭代设计是如何把复杂的需求给简单化的。把握迭代设计有助于我们避免过分设计的毛病。这是个技术人员经常犯的毛病。我所在的团队很多时候也无法避免。例如，在很多的项目中，我们都会花费大量的时间来设计数据库到业务实体的映射。诸如此类的技术问题对开发人员的吸引程度是不言而喻的，但是必须看到，这种的设计会导致开发成本的大幅度上升。更为糟糕的是，除非有丰富的经验，这种类型的设计给开发工作带来的价值往往无法超过其成本。
因此，我们需要学会权衡利弊，是否有必要投入大量的资源来开发其实并没有那么有用的功能。因此，迭代设计和简单设计的结合有助于我们摆脱过度设计的困扰，把精力集中在真正重要的功能之上。
此外，简单的设计并不等同于较少的付出。简单的设计往往需要对现实世界的抽象，回忆我们在简单设计中讨论的测量模式的例子，它看似简单，但实现起来却需要大量的业务知识、很强的设计能力。因此，做到简单是程序员不断追寻的目标之一。
在很多的方法论中，一般并不过分注意代码重复的问题，要么是不关注，要么认为适当的代码重复是允许的。而XP却把代码重复视为良好代码的大敌。"只要存在重复代码，就说明代码仍有Refactoring的可能。"这种观点看起来非常的绝对，这可能也正是其名字中Extreme的来历（英文中的Extreme属于语气非常重的一个单词）。从实践的角度上来看，追求不重复的代码虽然很难做到，但是其过程却可以有效的提高开发团队代码的写作质量，因为它逼迫着你在每次迭代重对代码进行改进，不能有丝毫的怠惰。而这种迭代的特性，促进了简单的实现。
团队和简单
我们在简单设计中提过简单设计需要全面的设计师。除此之外，它还需要团队的配合。简单意味着不同活动间交付工件的简单化。也就是说，类似于需求说明书、设计文档之类的东西都将会比较简单。正因为如此，我们很难想象一个地理上分布在不同地点的开发团队或一个超过50人的大团队能够利用这种简单的文档完成开发任务。
因此，简单的设计是需要团队的组织结构来保证的。简单的设计要求团队的相互沟通能够快速的进行。架构设计完成后，架构的设计思路传达给所有的编码人员的速度要块，同样，编码中发现问题，回馈给设计者，设计者经过改进之后再传达给收到影响的编码人员的速度也要快。象这样高效率的传播我们可以称之为"Hot Channel"。
为了保证"Hot Channel"的高沟通效率，最好的组织单位是开发人员在3到6人之间，并处于同间工作室中。这样的结构可以保证讯息的交互速度达到最高，不需要付出额外的沟通成本，也不需要过于复杂的版本控制工具或权限分配。根据我的经验，一个共享式的小型版本控制工具、网络共享、再加上一个简单的网络数据库就能够解决大部分的问题了。
在理论上，我们说只要分配得当，大型的团队同样可以组织为金字塔式的子团队，以提高大型团队的工作效率。但是实际中，随着团队的人数的增加，任务的正确分配的难度也随之加大，沟通信息上传下达的效率开始下降，子团队间的隔阂开始出现，各种因素的累加导致敏捷方法并不一定适合于大型的团队，因此我们讨论的敏捷方法都将受到团队的特性的限制。
模式的源头
如果你对XP有一定的了解的话，那么你可能会感觉到我们讨论的模式中应用了XP的实践。确实如此，XP中有很多优秀的实践，如果组织得当的话，这些微小的实践将会组合成为一套了不起的开发方法。不过，目前的软件开发混乱的现状阻止了先进的软件方法的应用，对一个身体虚弱的病人施以补药只会适得其反。因此，在前面讨论的模式中，我们应用了一些容易应用、效果明显的实践方法。在实践中适当的应用这些方法，并不需要额外的投入，却能够有很好的效果，同时还会为你的团队打下一个良好的基础。
|
| threehair 回复于：2003-08-27 08:45:12
|
敏捷思维－架构设计中的方法学(
架构愿景
--------------------------------------------------------------------------------
来自：IBM China 作者：林星 [2003/04/17]
从这一篇开始，我们将会进入另一个不同的主题，和前面所讨论的模式专注于组织、过程、方法不同，以后介绍的模式更偏重于设计。但是过程、方法的影子依然在我们的讨论中隐约可见。
架构愿景是一个很简单的模式，在软件开发中所占的时间也很短。但是这并不意味着架构愿景不重要。相反，它会是设计过程不可或缺的一环。
Context
在单次的迭代开始阶段，我们已经收集好了单次迭代的需求。
Problem
架构和分析设计是密不可分的，有时候很难说得清楚架构的定义，但架构应该能够描述软件的整体。架构包括了软件的各个方面，但是每一个设计细节总是需要单独考虑，这时候就会出现设计细节之间、以及设计细节和架构之间的不一致。
架构设计的各个部分之间的设计冲突是很容易发生的。发生的概率及频率和团队的规模成正比、和沟通的频度及效果成反比。在很多次的项目开发过程中，我们发现了多处的相同功能的代码，原因是代码的作者并不知道别人已经实现了这个功能了。这可能只是浪费了一点精力，可如果不同模块间的设计冲突导致了软件无法正常运行的时候，我们就需要坐下来好好的审视，究竟发生了什么。
Solution
我们需要建立一个架构愿景。架构愿景应该能够提供软件全局视图，包括所有的重要部分，定义了各个部分的责任和之间的关系，而且还定义了软件设计需要满足的原则。而这个架构愿景的设计，应该是满足源自需求模式的，也就是说，部分的划分和部分的设计，都是根据需求而进行的。同时，架构愿景应该要能够满足架构的其它各种特点，例如简单、可扩展性、抽象性。简单来说，我们把架构愿景当作是一个mini的架构设计。
由于我们是在单次的迭代中讨论架构愿景，因此从整体上考虑，架构愿景是也是在不断的变化的。这是很自然的，因为架构愿景代表了架构的设计，架构愿景的演进代表了架构设计的演进。
架构的愿景是相对于一个范围来说的，在一个特定的软件功能范围之内，谈架构愿景才有实际的意义，例如针对软件的全局或某个子模块。在这个特定的范围中，订立了架构愿景之后，这个范围内的所有设计原则将不能违背架构愿景。这是非常重要的，是架构愿景的最大的用处。有了这样的保证，我们就可以保证设计的一致性和有效性。任何一项设计的加入，都能够融入到原先的架构中，使得软件更加的完善，而不是更加的危险。
当然，要做到这一点并不是一件容易的事情。特别需要指出的是，架构愿景模式仅仅是实现该目的的一条道路，并不是一个充分条件。如果在设计中愿景不能够贯彻其意志，或是愿景制定本身就存在问题，那么要想达到上述的效果，几乎是不可能的事情。此外，该模式仅仅只是达到该目的的第一步，我们在接下去的模式中会发现还需要很多方面的配合。
架构愿景的层次
我们根据架构适用范围的不同，把架构愿景分为几个类别讨论：
软件全局
软件全局的架构是我们所最关心的，因此也会花费最多的笔墨。
软件全局中的架构愿景一般很难具体化到代码级别，其实你会发现，就算是具体化到了代码级别，也会因为实际中存在的问题，导致代码没有太多的价值。因此，为软件全局设置的架构愿景可以以原则、或是模式名的方式体现，并用自然语言或伪代码描述。例如，可以为一个系统规定三层架构作为其愿景，并指出三层的分类原则。注意，我们需要指出分类原则，否则规定三层架构并没有太大的意义，因为三层架构随着实现平台的不同、开发人员的不同而有很大的差异，如果不能够规定一个可操作的规范，那么愿景是没有意义的。在Java环境下，我们可以这样说：
"客户端采用前端浏览器界面，业务逻辑采用servlet，配合JSP编写，浏览器到服务器的数据采用集中处理，具体的方法是在业务逻辑和前端浏览器之间采用Front Control模式，接受前端浏览器传送过来的数据，并指派给相应的业务逻辑处理。数据的合法性检验分为两个部分：和业务逻辑无关的基本合法性验证在前端使用Java Script处理，和业务逻辑相关的合法性验证在业务逻辑层处理，可以使用一个集中的servlet专门处理错误情况。"
而在Windows环境下，我们知道三层结构的分界和Java中的并不相同（关于这一点，下一篇的文章中将会有详细的描述），我们可以在业务逻辑层或显示层直接操纵数据，非常的方便，因此，在Windows中的架构愿景的描述又不一样。另外，在非面向对象的环境中，在分布式的环境中，在Lotus Notes的环境中，其架构的描述都不一样。
注意到，架构愿景的制定是根据不同的应用环境而变化的，这一点我们在文章的一开始就强调过，这里又出现了相同的问题。我们可以通过一个简单的例子来加深对这个问题的理解。在Java的环境下，特别是J2EE的环境下面，经典的设计思路是把数据库的一张表视作一个类，表中的每一行都是这个类的一个具体的实例，表的每一个字段对应了类的一个变量，类一般支持Find方法，来获取数据不同的实例。这是一种很自然的设计思路，而且可以通过CMP等技术来简化设计的繁琐步骤。可是，在Windows环境下，相信没有多少人会这么做。常用的处理方法是使用记录集（RecordSet）的方式，也就是说针对一组的记录来进行操作，而不是单个的记录。这些记录可以是跨表的（使用SQL的连接），也可以是单表的。由于Windows环境下大多数的编程语言都能够支持记录集方式，因此编写基于记录集方式的程序是相当简单的。当然，我们也可以采用J2EE平台的编程方式，但是会导致编程量的激增，同时也难以达到预计的效果。这种平台的差别导致了架构愿景的差别。
此外，我们注意到我们对架构的描述其实还是不够仔细，这是非常正常的，因为随着开发的深入，我们会不断的完善架构的描述。例如，我们可以写出Front Controll的类框架，写出主要的几个Servlet，以及他们之间的关系。这个时候，使用UML类图会是一个不错的选择，实际上，我非常推崇在架构设计中大量的使用类图。不过在实际的运作中，每个软件团队大多数都有自己熟悉的架构设计思路，使用何种工具并不是主要的问题。
我们从源自需求模式中，学习到架构的设计是来自于需求的，而应用于软件全局的架构则来自于最重要的需求。还记得我们在那个模式中提到的网上宠物店的例子吗？系统采用了MVC模式，sun的官方文档一开始说明了为什么采用MVC模式，MVC模式解决了什么问题，然后开始分析MVC模式的几个组成部分：Model、View、和Controll。其实，MVC中的每一个部分，在真正的代码中，大都代表了一个子系统，但是在目前，我们就非常的清楚系统大致上会是一个什么样子，虽然这时候它还十分的朦胧。
不要视图在全局的架构愿景中就制定出非常细致的规划，更不要视图生成大量的实际代码。因为，你的架构愿景还没有稳定（我们在其后的稳定化的模式中将会讨论稳定的问题），还没有获得大家的同意，也没有经过证明。因此，从整个的开发周期来看，全局架构愿景是随着迭代周期的进行不断发展、修改、完善的。
我们如何确定全局架构愿景工作的完成？一般来说，你的架构设计团队取得了一致的意见就可以结束了，如果问题域是团队所熟悉的，一两个小时就能够解决问题。接下来设计团队把架构愿景传播到整个的开发团队，大家形成一致的认识，不同的意见将会被反馈会来，并在本次的迭代周期（如果时间比较紧迫）或下一次的迭代周期中（如果时间比较宽松）考虑。
子模块级、或是子问题级的架构愿景
这时候的架构愿景已经是比较明确的了，因为已经存在明确的问题域。例如界面的设计、领域模型的设计、持久层的设计等。这里的愿景制定本质上和全局的愿景制定差不多，具体的例子我们也不再举了。但是要注意一点，你不能够和全局愿景所违背。在操作上，全局愿景是设计团队共同制定出来的，而子模块级的架构愿景就可以分给设计子团队来负责，而其审核则还是要设计团队的共同参与。这有两个好处，一是确保各个子模块（子问题）间不至于相互冲突或出现空白地带，二是每个子设计团队可以从别人那里吸取设计经验。
在设计时，同样我们可以参考其它的资料，例如相关的模式、或规范（界面设计指南）。在一个有开发经验的团队，一般都会有开发技术的积累，这些也是可供参考的重要资料。
我们在这个层次的愿景中主要谈一谈子模块（子问题）间的耦合问题。一般来说，各个子模块间的耦合程度相对较小，例如一个MIS系统中，采购和销售模块的耦合度就比较小，而子问题间的耦合程度就比较大，例如权限设计、财务，这些功能将会被每个模块使用。那么，我们就需要为子模块（子问题）制定出合同接口（Contact Interface）。合同的意思就是说这个接口是正式的，不能够随意的修改，因为这个结构将会被其它的设计团队使用，如果修改，将会对其它的团队产生无法预计的影响。合同接口的制定、修改都需要设计团队的通过。此外，系统中的一些全局性的子问题最好是提到全局愿景中考虑，例如在源自需求模式中提到的信贷帐务的例子中，我们就把一个利息计算方式的子问题提到了全局愿景中。
代码级的愿景
严格的说这一层次的愿景已经不是真正的愿景，而是具体设计了。但是我们为了保证对架构设计理解的完整性，还是简单的讨论一下。这一个层次的愿景一般可以使用类图、接口来表示。但在类图中，你不需要标记出具体的属性、操作，你只需要规定出类的职责以及类之间的相互关系就可以了。该层次愿景的审核需要设计子团队的通过。
而设计细分到这个粒度上，执行愿景设计的开发人员可能就只有一两个左右。但是比较重要的工作在于问题如何分解和如何归并。分解主要是从两个维度来考虑，一个是问题大小维，一个是时间长短维。也就是说，你（设计子团队负责人）需要把问题按大小和解决时间的长短分解为更细的子问题，交给不同的开发人员。然后再把开发人员提出的解决方法组合起来。
架构愿景的形成过程
架构愿景的形成的源头是需求，需要特别指出的是，这里的需求主要是那些针对系统基本面的需求。比如说，系统的特点是一个交互式系统，还是一个分布式系统。这些需求将会影响到架构愿景的设计。在收集影响架构愿景的各项需求之后，按照需求的重要性来设计架构愿景。
架构愿景的设计并不需要很复杂的过程，也不需要花费很多的时间。我们已经提过，架构远景的主要目的就是为了能够在开发团队中传播设计思路，因此，架构愿景包括基本的设计思路和基本的设计原则。
值得注意的是，架构远景可能会有多种的视角，下文讨论了一种设计模式的视角。但是实际设计中还可能会基于数据库来设计架构愿景。但在企业信息系统的设计中，我推荐使用领域类的设计，也就是下文中讨论的例子。
架构愿景设计好之后，问题的焦点就转到如何传播架构愿景上来，为了达到在开发团队中取得统一设计意图的效果，可以考虑援引团队设计模式。除此之外，针对性的项目前期培训也会是一种有效的做法。
使用架构模式
架构模式也是一种很好的架构愿景设计思路的来源。随着对设计模式的研究的深入，人们发现其中的一些设计模式可以扩展、或变化为软件设计的基础。在这个基础上再实现更多的设计，这些模式就形成了架构模式。当然，不同的软件，它们的架构模式也是不一样的。在《Applying Pattern》一文中，有一个很典型的架构愿景的例子：
假设我们需要设计分布式的交互式系统。分布式系统和交互式系统都有特定的架构模式，前者为Broker模式，后者为MVC模式。首先我们先要根据系统的特点的重要程度来排列模式的顺序。这里假设需求中分布式特性更重要一些。那么我们首先选择Broker模式作为架构的基本模式：
再考虑交互式的特点，根据MVC模式的特点，我们需要从目前的基本架构中识别出Model、Controller、以及View。Model和View都很简单，分别分布在上图中的Server和Client中。而Controller则有两种的选择，假设这里的Controller部署在客户端，上图则演化为下图：
这样，基础的架构愿景就已经出现了。如果我们还有更多的需求，还可以继续改进。但是，记住一点，架构愿景不要过于复杂。正如我们在上一节中所讨论的，这里我们虽然是基于设计模式来讨论架构愿景，但是实际中还有很多从其它的视角来看待架构愿景的。至于要如何选择架构愿景的视角，关键的还是在于需求的理解。
|
演化图：
|
Broker模式作为架构的基本模式：
| | threehair 回复于：2003-08-27 08:49:05
| 敏捷思维－架构设计中的方法学(9)
分层 (上)
--------------------------------------------------------------------------------
来自：IBM China 作者：林星 [2003/04/17]
在定义了架构愿景之后，团队中的所有人员应该对待开发的软件有一定的了解了。但是，面对一个庞大的软件系统，接下来要做些什么呢？分而治之的思想是计算机领域非常重要的思想，因此我们也从这里开始入手。
要进行应用软件的设计，分层是非常重要的思想，掌握好分层的思想，设计出的软件是可以令人赏心悦目的。由于这一章的重要性和特殊性，本章的内容分为上下两节，并不采取模式描述语言的方式。
分层只是将系统进行有效组织的方式。 本章特别针对于企业应用进行讨论，但其中大部分的内容都可以应用在其它的系统中，或为其它的系统所参考。
在企业应用中，有两个非常重要的概念：业务逻辑和持久性。可以说，企业应用是围绕着业务逻辑进行开展的。例如报销、下订单、货品入库等都是业务逻辑。从业务逻辑的底层实现来看，业务逻辑其实是对业务实体进行组织的过程。这一点对于面向对象的系统才成立，因为在面向对象的系统中，识别业务实体，并制定业务实体的行为是非常基础的工作，而不同的业务实体的组合就形成了业务逻辑。
还有另一个重要的概念是持久性。企业应用中大部分的数据都是需要可持久化的。因此，基础组织支持持久性就显得非常的重要。目前最为通行的支持持久性的机制是数据库，尤其是关系性数据库－RDBMS。
除此之外，在企业应用中还有其它的重要概念，例如人机交互。
为了能够更有效的对企业中的各种逻辑进行组织，我们使用层技术来实现企业应用。层技术在计算机领域中有着悠久的历史，计算机的实现中就引用了分层的概念。TCP/IP的七层协议栈也是典型的分层的概念。分层的优势在于：
上层的逻辑不需要了解所有的底层逻辑，它只需要了解和它邻接的那一层的细节。我们知道TCP/IP协议栈就是通过不同的层对数据进行层层封包的，不同层间的耦合度明显降低。通过严格的区分层次，大大降低了层间的耦合度。
某一层次的下级层可以有不同的实现。例如同样的编程语言可以在不同的操作系统和不同的机器中运行。
和第三条类似的，同一个层次可以支持不同的上级层。TCP协议可以支持FTP、HTTP等应用层协议。
综合上面的考虑，我们把企业应用分为多个层次。企业应用到底应该分为几种层次，目前还没有统一的意见。
在前些年的软件开发中，两层结构占有很重要的位置。例如在银行中应用很广的大型主机/终端方式，以及Client/Server方式。两层的体系结构一直到现在还广泛存在，但是两层结构却有着很多的缺点，例如客户端的维护成本高、难以实现分布式处理。随着在两层结构的终端用户和后端服务间加入更多的层次，多层的结构出现了。
经典的三层理论将应用划分为三个层次：
表示层（Presentation Layer），用于处理人机交互。目前最主流的两种表示层是Windows格式和WebBrowser格式。它主要的责任是处理用户请求，例如鼠标点击、输入、HTTP请求等。
领域逻辑层（Domain Logic Layer），模拟了企业中的实际活动，也可以认为是企业活动的模型。
数据层（Data source Layer），处理数据库、消息系统、事务系统。
在实际的应用中，三层结构有一些变化。例如，在Windows的.NET系统中，把应用分为三个层次：表示层（Presentation Layer）、业务层（Business Layer）、数据访问层（Data Access Layer），分别对应于经典的三层理论中的三个层次。值得一提的是，.NET系统中表示层可以直接访问数据访问层，即记录集技术。在ADO.NET中，这项技术已经非常成熟，并通过表示层中的某些数据感知组件，实现非常友好的功能。这种越层访问的技术通常被认为是不被允许的，因为它可能会破坏层之间的依赖关系。而在Windows平台中，严格遵守准则就意味着需要大量额外的工作量。因此，我们看到准则也不是一成不变的。
在J2EE的环境中，三层结构演变为五层的结构。在表示层这里，J2EE将其分为运行在客户机上的用户层（Client Layer），以及运行在服务端上的Web层（Presentation Layer）。这样做的主要理由是Web Server已经成为J2EE中非常核心的技术，例如JSP和Java Servlet都和它有关系。Web层为用户层提供表示逻辑，并对用户的请求产生回应。
业务层（Business Layer）并没有发生变化，仍然是处理应用核心逻辑之处。而数据层则被划分为两个层次：集成层（Integration Layer）和资源层（Resource Layer）。其中，资源层并非J2EE所关心的内容，它可能是数据库或是其它的老系统，集成层是重要的层次，包括事务处理，数据库映射系统。
实例
这一章的的组织方式和之前的模式有一些差别。我们先从一个例子来体会架构设计中分层的重要性。
上图是一个业务处理系统的软件架构图。在上图中，我们把软件分为四个层次。这种层次结构类似于我们前面所谈的J2EE的分层。但是和J2EE不同的是，缺少了一个Web Server层，这是因为目前我们还没有任何对Web Server的需要。
在资源层上，我们有三种资源：数据库、平台服务、UI。数据库是企业应用的基础，而这里的平台服务指的是操作系统系统或第三方软件提供的事务管理器的功能。值得注意的是，这里的事务管理器指的并不是数据库内部支持的事务，而是指不同的业务实体间事务处理，这对于企业应用有着很重要的意义。因为对于一个企业应用来说，常常需要处理跨模块、跨软件、甚至跨平台的会话（Session），这时候，单纯的数据库支持的事务往往就难以胜任了。这方面的例子包括微软的MTS和Oracle的DBLink。当然，如果说，在你处理的系统中，可以使用数据库事务来处理大部分的会话的话，那就可以避免考虑这方面的设计了。除了典型的事务管理器，平台还能够提供其它的服务。对于大部分的企业应用来说，都是集成了多个的平台服务，平台服务对架构的设计至关重要。但是从分层的角度上考虑，上层的设计应该尽可能的和平台无关。和使用平台服务类似的，一般来说，企业应用都不会从头设计界面，大部分情况下都会使用现有的的UI资源。比如Window平台的MFC中的界面部分。因此，我们把被使用的UI资源也归到资源层这个层次上。
资源层的上一层是集成层。集成层主要完成两项工作，第一项是使用资源层的平台服务，完成企业应用中的事务管理。有些事务处理机制已经提供了比较好封装机制，直接使用资源层的平台服务就可以了。但是对于大多数的应用来说，平台提供的服务往往是比较简单的，这时候集成层就派上大用场了。第二项是对上一层的对象提供持久性机制。可以说，这是一组起到过渡作用的对象。它实际上使用的是资源层的数据库功能，并为上一层的对象提供服务。这样，上一层的业务对象就不需要直接同数据库打交道。对于那些底层使用关系型数据库，编程中使用面向对象技术的系统来说，目前比较常见的处理持久性的做法是对象/关系映射（OR Mapping）。
在这个层次上，我们可以做一些扩展，来分析层的作用。假设我们的系统需要处理多个数据库，而不同数据库之间的处理方式有一定的差异。这时候，层的作用就显示出来了。我们在集成层中支持对多个数据库的处理，但对集成层以上的层次提供统一的接口。对于业务层来说，它不知道，也不需要知道数据库的差别。目前我们自己开发了集成层中的持久类，但是随着功能的扩展，原有的类无法再支持新增加的功能了，新的解决方案是购买商用程序。为了尽可能的保持对业务层次的影响，我们仍然使用原有的接口，但是具体的实现已经不同了，新的代码是针对新的商业程序来实现的。而对业务层来说，最理想的状况是不需要任何的改变。当然现实中不太可能出现如此美好的情况，但可以肯定的一点是，引入层次比不引入层次要好的多。
以上列举的两个例子都是很好的解决了耦合度的问题。关于分层中的耦合度的问题，我们在下面还会讨论。
业务层的设计比较简单，暂时只是把它实现为一组的业务类。类似的，表示层的设计也没有做更多的处理。表示层的类是继承自资源层的。这是一种处理的方法，当然，也可以是使用关系，这和具体的实现环境和设计人员的偏好都有关系，并不是唯一的做法。在对软件的大致架构有了一个初步了解之后，我们需要进一步挖掘需求，来细化我们的设计。在前面的设计中，我们对业务层的设计过于粗糙了。在我们的应用中，还存在一个旧系统，这个系统中实现了应用规则，从应用的角度来看，这些规则目前仍然在使用，但新的系统中会加入新的规则。在新系统启用后，旧的系统中的规则处理仍然需要发挥它的作用，因此不能够简单的把所有的规则转移到新系统中。（有时候我们是为了节省成本而不在新系统中实现旧系统的逻辑）。我们第二步的架构设计的细化过程中将会加入对新的要求的支持。
在细化业务层的过程中，我们仍然使用层技术。这时候，我们把原先的业务层划分为两个子层。对于大多数的企业应用来说，业务层往往是最复杂的。企业对象之间存在着错综复杂的联系，企业的流程则需要用到这些看似独立的企业对象。我们希望在业务层中引入新的机制，来达到组织业务类的目的。业务层的组织需要依赖于具体的应用环境，金融行业的应用和制造行业的应用就有着巨大的差距。这里，我们从一般性的设计思考的角度出发来看待我们的设计：
|
|
业务处理系统的软件架构图
| | threehair 回复于：2003-08-27 08:50:57
| 首先，我们看到，业务层被重新组织为两个层次。增加层次的主要考虑是设计的重用性。从我们前面对层的认识，我们知道。较高的层次可以重用较低的层次。因此，我们把业务层中的一部分类归入较低的层次，以供较高的层次使用。降低类层次的主要思路是分解行为、识别共同行为、抽取共性。
在Martin Fowler的分析模式中提供了一种将操作层和知识层分离的处理方法：
Action、Accountability、Party属于较高层次的操作层（Operational Layer），这一层次的特点是针对于特定的应用。但是观察Accountability和Party，有很多相似的职责。也就是说，我们对于知识的处理并不合适。因此，Martin Fowler提出了新的层次――属于较低层次的知识层（Knowledge Layer）。操作层中可重用的知识被整理到知识层。从而实现对操作层的共性抽取。注意到虽然图中的层次（Level）的概念和层（Layer）有所差别，但是思路是基本一致的。
另一种分层方法是利用继承：
该图中也是来自于分析模式一书。不同的部门有着差异点和共性，将共性提取到父类中是继承的基本概念。这时候我们可以把父类看作是较低的层次，而把子类看作是较高的层次。对于一组层次结构很深的类来说，也可以从某一个水平线上分离层次。
最后一种方法需要分解并抽象对象的行为。C++的STL中为不同的数据类型和不同的容器实现了Iterator的功能。它的实现是典型的降低层次的行为。我们不考虑它对不同数据类型的支持，因为它使用了比较独特的模板（Template）技术，只考虑它对不同的容器的实现。首先是对共性的分析，不论是数组（Array）还是向量（Vector），要执行遍历操作，都需要知道三个条件：容器的起始点、容器的长度、匹配值。这就是一种抽象。通过这种方式，就可以统一不同容器的接口。
以上我们讨论了细分层次的好处和实现策略。下面我们回到前例中，继续讨论层中的各个部件。
业务实体指的是企业中的一些单独的对象。例如订单、客户、供应商等。由于业务实体可以被很多的业务流程（业务会话）所使用，因此我们把业务实体放在业务实体层中。企业中的业务实体大多是需要持久性的。因此在我们的设计中，业务实体将持久性的职责委托给下一个层次中的持久性包，而不是直接调用数据库方法。另一种常用的方法是使用继承――业务实体继承自持久类。EJB中的Entity Bean就是典型的业务实体，它可以支持自动的持久性机制。
在我们的系统中，规则是一个尴尬的存在。部分的规则处于旧系统中，并使用旧系统的持久性机制。而新系统中有需要支持新的规则。对于上层的用户来说，并不需要知道新旧系统的规则。如果我们在使用规则时做一个新旧规则的判断并调用不同的系统函数，那就显得太傻了。我们的设计对上层而言应该是透明的。
所以我们总共设计了三个包来实现规则的处理。包装器包装了旧系统中的规则，这样做处于几点考虑：首先，旧系统是面向过程的，因此我们需要用包装器将函数（或过程）封装到类中。其次，对旧系统的使用需要额外的程序（或平台服务）的支持，因此需要单独的类来处理。最后，我们可以使用Adapter模式[GOF 94]将新旧系统不同的接口给统一起来，以使他们能够一起工作。新的规则类实现了新的规则，较好的做法是定义一个虚协议，具体的表现形式可以是虚基类或接口。然后由其子类实现虚协议。再结合前面介绍的把旧规则的接口转换为新的接口的方法，就能够统一规则接口。从图中我们看到，业务实体需要使用规则，通过统一的接口，业务实体就能够透明的使用新旧两种规则。
在定义了规则和标准的规则接口之后，上一层的规则控制器就可以通过调用规则，来实现不同规则组合。因此这个规则控制器就类似于应用规则。在业务交易处理中需要调用规则控制器来实现部分的功能。
请注意，这里讨论的思路虽然非常的简单、清晰，但是现实中的处理却没有这么容易。因为为新旧规则制定统一的接口实在是太难了。要能够使接口在未来也相对的稳定更是难上加难。而在应用已经部署之后，对已发布的接口的任何一个小改动都意味着很高的成本。在这个问题上，并没有什么好的策略，经验是最重要的。在实际中的一个比较实用的方法是为接口增加一些额外的参数。即便可能这个参数当前并没有使用到，但是如果为了有可能使用的话，那还是加上吧。举个例子，对于商业应用软件而言，数据库，或者说是关系数据库一定是不可缺少的部分。大量的操作都需要和数据库结合起来，因此，可以考虑在方法中加入一个数据库连接字符串的参数。虽然这对于很多方法而言是没什么必要的，但是为将来的实践提供了一个可扩展的空间。国内的某个知名的ERP软件的设计就采用了这种思路。
本章的主要精力都放在实例的研究上，在有了一个基本的概念之后，我们再回来谈谈分层的一些原则和需要注意的问题。
|
利用继承
|
Martin Fowler的分析模式
| | threehair 回复于：2003-08-27 08:53:18
| 敏捷思维－架构设计中的方法学(10)
分层 (下)
--------------------------------------------------------------------------------
来自：IBM China 作者：林星 [2003/04/17]
上篇我们用了大量的篇幅来观察了一个实际的例子，相信大家已经对分层有了一个比较具体的概念了。在这一篇中我们就对分层在实践中可能会遇到的问题做一个讨论。分层在架构设计中是一种非常常见的，但是又很不容易用好的技术。因此我们这里花了很大的气力来讨论它。
由于这是一篇介绍软件设计技术的文章，为了尽可能让更多的人理解，本应该尽可能不涉及到过于具体的技术或平台。但是这个目标可能很难实现，因为软件设计是没办法脱离具体的实现技术的。因此本文能够做到的是尽可能的不涉及具体的编码细节。
何时使用分层技术？
分层技术实际上是把技术复杂化了。和以往简单的CS结构的系统不同，分层往往需要使用特定的技术平台来实现。当然，不使用这些技术平台也是可能的，但是效果可能就没有那么好了。支持分层技术的平台有很多，包括目前主流的J2EE和.NET。甚至在不同厂商的开发平台上，要求也不一样。使用分层技术实现的多层架构，成本要比普通的CS架构高得多。
这就产生了一个非常现实的问题－并不是所有的软件都适合采用分层技术的。一般来说，小型的软件使用分层并没有太大的意义，因为分层导致的成本超过它所能带来的好处。在一般的CS结构中，可以把界面控制、逻辑处理和数据库访问都放在一块儿。这种设计方式在纯粹的多层主义者看来简直就是十恶不赦。但是对于小型的软件而言，这并不是什么大不了的事情。因为从表示层到数据层的整套功能都被囊括在一个功能块中，同样能够实现较好的封装。而且，如果结构设计的足够好，也能够避免表示层、业务层和数据层之间出现过高的耦合度。因此，除非确实需要，不然没有必要使用分层技术。
尤其在处理一些特殊的项目时，严格的区分三层结构并不理想。比如在快速开发windows界面的应用时，往往会用到一些对数据库敏感的控件，这种处理方法跨越了三个层次，但是却很实用，成本也比较低。又比如一些框架，给出了从界面层到数据库的综合的解决方案，和windows的应用类似，严格的三层技术也不适用于这种情况。
如何使用分层技术？
从某种意义上来看，层其实是一个粗粒度的组件。就像我们使用组件技术是为了对系统进行一种划分一样，层的一个很大的作用也是如此。其目的是为了系统更容易被理解，不同的部分能够被较容易的替换。
使用分层技术的依据是软件开发人员的实际需要。如果你是在使用某些优秀的面向对象的软件开发平台的话，那它们一般都会建议（或是强制）你使用某一种分层机制。这是你采用分层技术的一大参考。
对于大多数有一定经验的软件团队而言，一般都会积累一些软件开发经验。其中包含了很多在某些特定的领域中使用的基础的类或组件。这些元素构成了一个系统的通用层次。这个层次也是分层时需要考虑的。例如一些应用软件中使用的一些通用的Currency对象或是Organization对象。分析模式一书对此类的对象进行了充分细致的阐述。这个层次一般被称为跨领域层（cross-domain layer），或称为工具层（utility layer）。
目前的很多软件都采用了数据库映射技术。数据库映射层对于企业应用系统非常的重要，因此也需要纳入考虑之列。数据库映射技术用起来简单，但是要实现可不容易。如果不是非常有必要，尽可能使用现成的框架，或是采用其中部分的设计思路。试图构建一个大而全的映射层次的代价是非常高昂的，认识不到这一点会带来很大的麻烦。数据库映射技术的知识，我们在下文中还有专门的篇幅来讨论。
如何存放数据（状态）？
在学习EJB的过程中，最先要理解的一定是有状态和无状态的概念。可以说，整个概念是多层体系的核心。为什么这么说呢？这里的状态指的是类的状态，例如类的属性、变量等。由于状态的不同，类也表现出差异来。而对于多层结构的软件，创建和销毁一个类的开销是很大的，如果该软件支持分布式的话尤为如此。所以如果系统的不同层次间进行频繁的调用－创建一个类，再销毁一个类。这种做法是非常消耗资源的。在应用系统的设计中，一般不单独使用COM，就是这个原因。所以我们很自然的想到了一种经典的设计－缓冲池。把对象存放在缓冲池中，当需要的时候从池中取出一个，当不需要的时候再把对象放入池中。这种设计思路能够大幅度的提高效率。但是这对能够放在池中的对象也提出了苛刻的要求－所有的对象必须是无差异的，也就是无状态的。只有这样才能够实现缓冲池。
一般来说，对象缓冲池的技术是用在中间的业务层上的。既然中间业务层上不能够保留有状态，那就出现了一个状态转移的问题。这里有两种的选择，一种是前移，把状态移到用户端，最典型的是使用cookie。这种选择一般是由于状态和用户端有关，不需要长时间保存。另一种选择是后移，把状态移到数据层，由数据库来实现持久性状态，当需要时才把状态提交给业务层。这种方式是企业应用软件中采用最多的，但是也增大了数据库的负担。
处理好接口
由于使用了分层技术，因此原先那种在CS结构中类之间存在复杂关系就有必要重新评估了。一般层间的耦合度不宜过大。因此需要慎重的设计层之间的类调用方式。一些分布式软件体系（例如J2EE）对层之间的调用方式以接口的形式给出了要求。同时，不同层之间仅仅知道目标层的接口，而不知道目标层的具体实现。EJB的home接口和remote接口就是这样。在COM+体系中，也需要在设计类的同时，把接口公布出来，以供客户方使用。
在设计层间的接口时，除了考虑开发平台的约束之外，还有一点是开发人员必须考虑的。那就是业务需要。业务层中往往有非常多的对象和方法，它们之间的关系也非常的负责，但对于其它的层次来说，它并不关心这些细节。因此业务层公布的接口必须要简单，而且和实现无关。因此，可以使用设计模式的Facade模式来简化层间的接口。这种做法非常有效，EJB中的SessionBean和EntityBean区分就含有这种设计思路。
同样的，不同层之间的数据传递也存在问题。如果不同层的物理节点在一起还好办，如果不在一起，那就需要使用到分布式技术了。因为不同机器的内存地址编码是不同的，如果接口之间采用对象引用的方式，那一定会出现问题。因此会将对象打包成字符串，发送到目标机器后再还原为对象。所有的分布式平台都提供了对这种技术的支持，这里就不多说了。但是这种实现技术会对我们的设计思路产生影响，少量的数据直接使用字符串来传递，数据量大的话，就需要使用封装了数据的对象。这类对象的设计需要非常的小心。在设计过程中可以参照开发平台提供的一些标准做法。同样的，数据的请求的频率也是难点之一。过于频繁的操作来自后端的数据会加大系统的开销。因此，在设计调用方法时同样需要结合实际应用来考虑。
兼顾效率
一般来说，纯粹的面向对象设计者设计出的软件都会比较完美。但是需要付出一定的代价。在一些大的软件平台上编程的时候，往往需要利用到平台的一些机制。最典型的就是平台的事务机制（最典型的包括J2EE平台的JTS，以及COM+平台的MTS），但是事务机制的实现往往需要平台大量对象的支撑。这种情况下，创建一个支持事务的对象的开销是很大的。处理这种问题有一种变通的办法，就是仅仅对需要事务支撑的对象提供事务支持。这就意味着，一个单独的业务实体类，可能需要根据是否支持事务分为两种类：对该业务实体的select方法不需要事务的支持，只有update和delete方法才需要有事务的支持。这是不符合纯面向对象设计者的观点的。但是这种做法却可以获得比较优秀的效率。
图1 将单个的业务实体分为不同的实现
应该承认，这种提高效率的做法加大了复杂度。因为对于客户端来说，它们并不关心具体的实现技术。要求客户端在某一种情况下调用这个类，在其它情况下又调用另一个类，这种做法既不符合面向对象的设计思路，也增大了层间耦合度及复杂性。因此，我们可以考虑使用接口或是外观类（参见设计模式一书中的facade模式），把具体的实现封装起来，而只把用户关心的部分提供给用户。这方面的技巧我们在下面的章节中还会提到。
以迭代的方式进行分层
软件设计中的迭代做法同样可以适用于分层。根据自己的经验，在一开始就定义好所有的层次是很难的。除非有着非常丰富的经验，都则实现和原先的设计总有或大或小的差距。因此调整势在必行。每一次的迭代都能够对分层技术进行改进，并为后一个项目积累了经验。
这里的分层迭代不可以过于频繁，每一次的迭代都是对架构的重大修改，都是需要投入人力的，而且会影响到软件开发的进度。但是成功的迭代的效果是非常明显的，能够在接下来的开发周期中起到稳定架构，减少代码量，提升软件质量的功效。注意，不要让新潮技术成为分层迭代的推动力。这是开发人员都常犯的毛病，这并不是什么缺点，只能称为一种职业病吧。分层迭代的推动力应该源自于需求的演进以及现有架构的不稳定已经妨碍了软件进一步的开发。因此这需要团队中的技术主管对技术有着非常好的把握。
重构能够对迭代有所帮助。嗅出代码中隐藏的坏味道并加以改进。应该说，迭代是一种比较激烈的做法，更好的做法是在开发中不断的对架构、层次进行调整。但这对团队、技术、方法、过程都有着很高的要求。因此迭代仍然是一种主要的改进手段。
层内的细分
分层的思路还可以适用于层的内部。层内的细分并没有固定的方式，其驱动因素往往是出于封装性和重用的考虑。例如，在EJB体系中的业务层中，实体Bean负责实现业务对象，因此一个应用往往拥有大量的实体Bean。而用户端并不需要了解每一个的实体Bean，对它们来说，只要能够完全一些业务逻辑就可以了，但完成这些业务逻辑则需要和多个实体Bean打交道。因此EJB提供了会话Bean，来负责把实体Bean封装起来，用户只知道会话Bean，不知道实体Bean的存在。这样既保证了实体Bean的重用性，又很好的实现了封装。
面向接口编程
在前面的章节中，我们提到一个接口设计的例子。为什么我们提倡接口的设计呢？Martin Fowler在他的分析模式一书中指出，分析问题应该站在概念的层次上，而不是站在实现的层次上。什么叫做概念的层次呢？简单的说就是分析对象该做什么，而不是分析对象怎么做。前者属于分析的阶段，后者属于设计甚至是实现的阶段。在需求工程中有一种称为CRC卡片的玩艺儿，是用来分析类的职责和关系的，其实那种方法就是从概念层次上进行面向对象设计。因此，如果要从概念层次上进行分析，这就要求你从领域专家的角度来看待程序是如何表示现实世界中的概念的。下面的这句话有些拗口，从实现的角度上来说，概念层次对应于合同，合同的实现形式包括接口和基类。简单的说吧，在概念层次上进行分析就是设计出接口（或是基类），而不用关心具体的接口实现（实现推迟到子类再实现）。结合上面的论述，我们也可以这样推断，接口应该是要符合现实世界的观念的。
在Martin Fowler的另一篇著作中提到了这样一个例子，非常好的解释了接口编程的思路：
interface Person {
public String name();
public void name(String newName);
public Money salary ();
public void salary (Money newSalary);
public Money payAmount ();
public void makeManager ();
}
interface Engineer extends Person{
public void numberOfPatents (int value);
public int numberOfPatents ();
}
interface Salesman extends Person{
public void numberOfSales (int numberOfSales);
public int numberOfSales ();
}
interface Manager extends Person{
public void budget (Money value);
public Money budget ();
}
可以看到，为了表示现实世界中人（这里其实指的是员工的概念）、工程师、销售员、经理的概念，代码根据人的自然观点设计了继承层次结构，并很好的实现了重用。而且，我们可以认定该接口是相对稳定的。我们再来看看实现部分：
public class PersonImpFlag implements Person, Salesman, Engineer,Manager{
// Implementing Salesman
public static Salesman newSalesman (String name){
PersonImpFlag result;
result = new PersonImpFlag (name);
result.makeSalesman();
return result;
};
public void makeSalesman () {
_jobTitle = 1;
};
public boolean isSalesman () {
return _jobTitle == 1;
};
public void numberOfSales (int value){
requireIsSalesman () ;
_numberOfSales = value;
};
public int numberOfSales () {
requireIsSalesman ();
return _numberOfSales;
};
private void requireIsSalesman () {
if (! isSalesman()) throw new PreconditionViolation ("Not a Salesman") ;
};
private int _numberOfSales;
private int _jobTitle;
}
这是其中一种被称为内部标示（Internal Flag）的实现方法。这里我们只是举出一个例子，实际上我们还有非常多的解决方法，但我们并不关心。因为只要接口足够稳定，内部实现发生再大的变化都是允许的。如果对实现的方式感兴趣，可以参考Matrin Fowler的角色建模的文章或是我在阅读这篇文章的一篇笔记。 通过上面的例子，我们可以了解到，接口和实现分离的最大好处就是能够在客户端未知的情况下修改实现代码。这个特性对于分层技术是非常适用的。一种是用在层和层之间的调用。层和层之间是最忌讳耦合度过高或是改变过于频繁的。设计优秀的接口能够解决这个问题。另一种是用在那些不稳定的部分上。如果某些需求的变化性很大，那么定义接口也是一种解决之道。举个不恰当的例子，设计良好的接口就像是我们日常使用的万用插座一样，不论插头如何变化，都可以使用。
最后强调一点，良好的接口定义一定是来自于需求的，它绝对不是程序员绞尽脑汁想出来的。
数据映射层
在各个层的设计中，可能比较令人困惑的就是数据映射层了。由于篇幅的关系，我们不可能在这个问题上讨论太多，只能是抛砖引玉。如果有机会，我们还可以来谈谈这方面的话题。
面向对象技术已经成为软件开发的一种趋势，越来越多的人开始了解、学习和使用面向对象技术。而大多数的面向对象技术都只是解决了内存中的面向对象的问题。但是鲜有提到持久性的面向对象问题。
面向对象设计的机制与关系模型有很大的不同，这造成了面向对象设计与关系数据库设计之间的 | | | | | | | | | | | | |
