引用Q?BR>
留意你的知觉
本能的直觉能对设计质量做Zo人惊讶的预测。所谓“出自本能的直觉”，是指当你看到某些不喜Ƣ的东西Ӟ你胃部的感觉。我知道q听hq不U学Q而且它的不U学Q，但我的经验L向我证明Q当我从直觉上不喜欢一个设计时Q一个更好的设计一定就w在角落里?BR>
Facade模式Q关键特?BR>
意图Q希望简化现有系l的使用Ҏ。你需要定义自q接口?BR>问题Q只需要用一个复杂系l的一个子集。或者，需要用一U特D的方式与系l交互?BR>解决ҎQFacade向客户展C用现有系l的一个新的接口?BR>参与者与协作者：向客户展C个定制的接口Q让客户更容易地使用现有pȝ?BR>效果QFacade模式化了Ҏ需子系l的使用。但是，׃Facadeq不完整Q因此某些功能对于客户可能是可用的?BR>现实Q?Q定义一个（或一l）新的cL提供所需要的接口?BR> 2Q让新的cM用现有的pȝ?BR>
Facade模式使用于以下情况：
- 不需要用一个复杂系l的所有功能，q且可以创徏一个新的类来包容访问原有系l的接口的一个子集（通常它就是）比原始系lAP单得多?/FONT>
- 希望包装或隐藏原有系l?/FONT>
- 希望使用原有pȝ的功能，q且希望增加一些新的功能?/FONT>
- “编写一个新的类”的代h于“让所有h学会使用原有pȝ”或“在未来l护整个pȝ”所需的代?BR>
]]>
一个项目通常分ؓ表示层、业务逻辑层和持久层，q是最为常见的三层l构。在l织团队q行目开发的时候，选择如何分工对版本控制有很大的媄响。团队在做开发的时候一般有两种模式Q按层开发和按功能开发?BR>
按层开发（本h赞同的模式）
在这U开发模式下Q每个开发h员的目录l构相对固定和独立。对于CVSq类按文件夹来控制权限的版本控制服务器来_比较Ҏ实现对开发h员权限的划分Q不易出现文件不同步而导致的版本混ؕ?BR>
另外Q这U开发模式下Q更能集中开发h员的注意力，不需要了解太多与本层无关的其他技术。将_全部集中在如何实现本层的功能上，更有利于写出功能强大Q运行稳定的代码。例如：开发业务逻辑层的开发h员，他不可避免的会写很多逻辑上基本上一致的代码Q在写代码的q程中，p从中扑և一些相对的共性，公q代码q行抽象Q从而避免了出现大量的重复代码。由于工作范围相对较，能有更多的时间去学习相关斚w的最新技术和解决ҎQƈ应用到程序中Q能使程序在实现方式上较为先q、优?BR>
老天是公q的Q万物有其好的一面也必然有其不好的一面，q种开发模式也不能例外。对于需求不明确Q无法定义相对固定的对外接口Ӟq中按层开发的模式有其无法避免的一个问题。各层开发h员需要在开发的q程中，反覆的修Ҏ口，以便适应于变化了的需求。这必然导致逻辑处理部分代码要做相应的修攏V?BR>
按功能开发（本h持保留态度Q?/B>
q种开发模式下Q开发h员的目录l构基本是项目的完整目录接口Q他们需要到各层ȝ写对应他们所开发的模块的所有代码。对于CVSq类版本控制服务器来_基本上是无法做到对开发h员权限的界定。很Ҏ造成版本控制混ؕQ导致文件版本不同步Q是在开发过E中使用了公共文件的开发h员不能保证同步。例如：一个文件ؓ多个开发h员所共同l护Q开发h员各自都需要在其中d自己功能所需要部分的代码。这样很Ҏ出现多个人同时修改一个文件的情况Q导致文件不同步而造成的版本乱?BR>
另外Q这U开发模式对开发h员的技术要求相对较高，它要求开发h员掌握各层中所需要的技术。从界面昄到数据持久化Q甚臛_|络通信都需要一个开发h员去实现。在功能实现架构不是很确定的情况下，E序代码中将会出现大量的重复代码Q因为每个h都有自己的实现机Ӟ而逻辑处理相同或相q的情况在同一层中出现频率又比较高。导致程序的整体l构不统一Q尽层ơ结构相同。得程序日后维护极度困难，大大的提高了l护成本。由于开发h员牵涉用的技术过多，也很难保证程序实现方式的先进性和优越性?BR>
]]>