对这个模式各个角色之间的协调情况也是一定要注意满足使用抽象工厂模式的条件。
例子2：DAO(Data Access Object)模式
DAO实际上是两个模式的组合，即Data Accessor 模式和 Active Domain Object 模式，其中 Data Accessor 模式实现了数据访问和业务逻辑的分离，而Active Domain Object 模式，其中Data Accessor模式实现了数据访问和业务逻辑的分离，而Active Domain Object 模式实现了业务数据的对象化封装，一般我们将这两个模式组合使用。
DAO模式通过对业务层提供数据抽象层接口，实现了以下目标： （1） 数据存储逻辑的分离
通过对数据访问逻辑进行抽象，为上层机构提供抽象化的数据访问接口。业务层无需关心具体的select,insert,update操作，这样，一方面避免了业务代码中混杂JDBC调用语句，使得业务落实实现更加清晰，另一方面，由于数据访问几口语数据访问实现分离，也使得开发人员的专业划分成为可能。某些精通数据库操作技术的开发人员可以根据接口提供数据库访问的最优化实现，而精通业务的开发人员则可以抛开数据曾德繁琐细节，专注于业务逻辑编码。
（2） 数据访问底层实现的分离
DAO模式通过将数据访问计划分为抽象曾和实现曾，从而分离了数据使用和数据访问的地称实现细节。这意味着业务层与数据访问的底层细节无关，也就是说，我们可以在保持上层机构不变得情况下，通过切换底层实现来修改数据访问的具体机制，常见的一个例子就是，我们可以通过仅仅替换数据访问曾实现，将我们的系统部署在不同的数据库平台之上。也可以引入工厂模式，实现“开闭原则”(Open-Close Principle) –对扩展开放，对修改封闭。
（3） 资源管理和调度的分离
在数据库操作中，资源的管理和调度是一个非常值得关注的主题。大多数系统的性能瓶颈往往并非集中于业务逻辑处理本身。在系统涉及的各种资源调
度过程中，往往存在着最大的性能黑洞，而数据库作为业务系统中最重要的系统资源，自然也成为关注的焦点。DAO模式将数据访问逻辑从业务逻辑中脱离开来，使得在数据访问层实现统一的资源调度成为可能，通过数据库连接池以及各种缓存机制(Statement Cache,Data Cache等，缓存的使用是高性能系统实现的一个关键所在)的配合使用，往往可以保持上层系统不变的情况下，大幅度提升系统性能。
（4）数据抽象
在直接基于JDBC调用的代码中，程序员面对的数据往往是原始的
RecordSet数据集，诚然这样的数据集可以提供足够的信息，但对于业务逻辑开发过程而言，如此琐碎和缺乏寓意的字段型数据实在令人厌倦。
DAO 模式通过对底层数据的封装，为业务曾提供一个面向对象的接口，使得业务逻辑开发员可以面向业务中的实体进行编码。通过引入DAO模式，业务逻辑更加清晰，且富于形象性和描述性，这将为日后的维护带来极大的便利。 5.主要软件生命周期模型有哪些，它们各自的优缺点和适用范围是什么？
（1）瀑布模型：把每个阶段当成瀑布中的一个阶梯，强调由上而下，互相衔接、逐级下落，固定次序。
优点：开发阶段清晰，便于评审、审计、跟踪、管理和控制。通过设置里程碑，明确每阶段的任务与目标。可为每阶段制定开发计划，进行成本预算，组织开发力量。通过阶段评审，将开发过程纳入正确轨道。严格的计划性保证软件产品的按时交付。瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。
缺点：由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样软件与用户见面的时间间隔较长，也增加了一定的风险。不可逆或很难可逆。在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。缺乏灵活性，不能适应用户需求的改变。开始阶段的小错误被逐级放大，可能 导致成本和质量失控，甚至软件产品报废。 返回上一级的开发需要十分高昂的代价。随着软件规模和复杂性的增加，软件产品成功的机率大幅下降。
适用范围：在开发时间内需求没有或很少变化。分析设计人员对应用领域很熟悉。低风险项目（对目标、环境很熟悉）。用户使用环境很稳定。用户除提出需求以外，很少参与开发工作。
（2）原型模型:快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。
优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。开发者与用户充分交流，可以澄清模糊需求，需求定义比其他模型好得多。开发过程与用户培训过程同步。为用户需求的改变提供了充分的余地。开发风险低，产品柔性好。开发费用低，时间短。系统易维护，对用户更友好。
缺点：所选用的开发技术和工具不一定符合主流的发展，快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。。开发者在不熟悉的领域中不易分清主次，原型不切题。产品原型在一定程度上限制了开发人员的创新。随着更改次数的增多，次要部分越来越大，“淹没”了主要部分。资源规划和
管理较为困难，随时更新文档也带来麻烦。只注意原型是否满意，忽略了原型环境与用户环境的差异。
适用范围：已有产品或产品的原型，只需客户化的工程项目。简单而熟悉的行业或领域。有快速原型开发工具。进行产品移植或升级。
(3)增量模型:融合了瀑布模型的基本成分和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性系列产生软件的一个可发布的增量。
优点：人员分配灵活，开始不用投入大量的人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。增量能够有计划的管理技术风险。客户无需等到整个系统的实现。第一个增量会满足他们大多数关键的需求，因此，软件马上就能使用。客户可以将早期的增量作为原型，从中获得对后面系统增量的需求经验。项目总体性失败的风险比较低。虽然可能在一些增量中遇到问题，但是其他一些增量将会成功地交付给客户。因为具有最高优先权的服务被首先交付，而后面的增量也不断被集成进来，这就使得最重要的系统服务肯定接受了最多的测试。这也就意味着在系统的最重要的部分，客户不太可能遇到，软件失败。
缺点：由于各个构件是逐渐并入已有的软件体系结构中，所以加入构件必须不破坏以构好的的系统部分，这需要软件具备开放式的体系结构。分析设计人员对应用领域不熟悉，难以一步到位。软件系统的组装和拆卸性不强、开发人员全局把握水平不高（没有数据库设计专家进行系统集成），或者客户不同意分阶段提交产品，则不宜采用这种模型。在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改的模型，从而使软件过程的控制失去整体性。
如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
适用范围：在整个项目开发过程中，需求都可能发生变化，客户接受分阶段交付。中等或高风险项目（工期过紧且可分阶段提交的系统或目标、环境不熟悉）。用户可参与到整个软件开发过程中。使用面向对象语言或第四代语言。软件公司自己有较好的类库、构件库。
(3)迭代模型
优点：在迭代之初，它不要求有一个相近的原型，而且适用范围很广，几乎适用于所有的项目开发。提高了团队生产力;在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础;它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。
缺点：迭代模型采取循环的工作方式，每次循环均使工作产品更靠近目标产品一次，这就要求项目组成员具有很高的水平并掌握先进的开发工具。反之，就会存在较大的技术风险和技能风险。
适用范围：在项目开发早期需求可能有所变化。分析设计人员对应用领域很熟悉。高风险项目。用户可不同程度地参与整个项目的开发过程。使用面向对象的语言或UML。使用CASE工具，如Rose。具有高素质的项目管理者和软件
研发团队。该模型一般用在中小型应用软件的开发上，系统软件的开发很少采用迭代模型。
(5)螺旋模型: 采用一种周期性的方法来进行系统开发。基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
优点：风险分析使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，可使一些极端困难的问题和可能导致费用过高的问题被更改或取消。螺旋模型支持用户需求的动态变化，客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性。为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力。并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。设计上的灵活，可以在项目的各个阶段进行变更。以小的分段来构建大型系统，使成本计算变得简单容易。
缺点：过多的迭代次数会增加开发成本，延迟提交时间。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。采用螺旋模型需要开发人员具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。要求用户参与阶段评价，对用户来说比较困难，不易取得好的效果。
适用范围：特别适用于庞大、复杂并具有高风险的系统。在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型。
(6)敏捷方法
优点：敏捷开发的总体目标是通过“尽可能早地、持续地对有价值软件的交付”，使客户满意。所以客户的需求模糊时能很好的工作
缺点：很多客户都有一些随着时间变化的业务需求，不仅表现在新发现的需求上，也表现在对市场变化做出反应的需求上。需求变化太多，软件修改也会变多，给开发人员带来很大困扰。只适合小规模项目
适用范围：只适合小规模项目
（7）喷泉模型：是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。
优点：需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型各个阶段没有明显的界限，开发人员可以同步进行开发。 有利于提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面向可能随时加入各种信息、需求与资料的情况。
适用范围：喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。
（8）变换模型：是基于形式化规格说明语言及程序变换的软件开发模型，它采用形式化的软件开发方法对形式化的软件规格说明进行一系列自动或半自动的程序变换，最后映射为计算机系统能够接受的程序系统。
优点：解决了代码结构经多次修改而变坏的问题，减少了许多中间步骤（如设计、编码和测试等）。