设计模式--结构模式--门面模式--Java
Facade PatternsIntent 目的?Providea unified interface to a set of interfaces in a subsystem. Facade defines ahigher-level interface that makes the subsystem easier to use.?为子系统提供一个统一的接口。?Fa?ade为子系统提供了一个高层的接口，使子系统更容易使用。
Applicability 适用范围? youwant to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, resultin more and smaller classes. This makes thesubsystem more reusable and easier to customize, but it also becomesharder to use for clients that don't need to customize it. A facade can provide asimple default view of the subsystem that is good enough for mostclients. Only clients needing more customizability will need to look beyond thefacade.? 你想为复杂的子系统提供一套简单的接口。子系统往往因为不断演化而变得越来越复杂。大多数模式在使用时，只会产生更多更小的类。使子系统更容易重用，更容易定制，但是他也会使那些不需要定制的用户变 得难以使用。Fa?ade模式可以为大多数客户提供一个简单易用的视图（一套接口）。而那些需要更多定制的用户可以跨过fa?ade提供的接口，而是用子系统内部的功能。
?there are many dependencies betweenclients and the implementation classes of an abstraction. Introduce a facade todecouple the subsystem from clients and other subsystems, thereby promotingsubsystem independence and portability.?客户程序与抽象类的实现部分之间存在着很大的依赖性。引入f a ca d e将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
?you want to layer your subsystems.Use a facade to define an entry point to each subsystem level. If subsystemsare dependent, then you can simplify the dependencies between them by makingthem communicate with each other solely through their facades.?当你需要构建一个层次结构的子系统时，使用f a c a d e模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过f a c a d e进行通讯，从而简化了它们之间的依赖关系。
structure 结构
example Compiler
Consequences 效果?Itshields clients from subsystem components, thereby reducing the number ofobjects that clients deal with and making the subsystem easier to use.?它屏蔽了客户与子系统，因此减少了客户端所需要类的数目，使子系统更容易使用。?Itpromotes weak coupling between the subsystem and its clients.?它减弱了客户与子系统之间的耦合关系。?Itdoesn't prevent applications from using subsystem classes if they need to. Thusyou can choose between ease of use and generality.
Related Patterns 相关模式
?AbstractFactory (3.1)模式可以与F a c a d e模式一起使用以提供一个接口，这一接口可用来以一种子系统独立的方式创建子系统对象。Abstract Factory也可以代替F a c a d e模式隐藏那些与平台相关的类。
?Mediator(5.5) 模式与F a c a d e模式的相似之处是，它抽象了一些已有的类的功能。然而，M e d i a t o r的目的是对同事之间的任意通讯进行抽象，通常集中不属于任何单个对象的功能。M e d i a t o r的同事对象知道中介者并与它通信，而不是直接与其他同类对象通信。相对而言，F a c a d e模式仅对子系统对象的接口进行抽象，从而使它们更容易使用；它并不定义新功能，子系统也不知道f a c a d e的存在。通常来讲，仅需要一个F a c a d e对象，因此F a c a d e对象通常属于Singleton (3.5)模式。
DAO
在开发中会经常对数据库中的数据进行查询或者修改，如果业务逻辑加入大量的JDBC应用代码必然会造成代码坏味道，业务逻辑与JDBC应用严重偶合在一起，会造成系统阅读困难，修改困难等。 这个时候在业务逻辑和数据库访问中间加上一层DAO—ata Acess Object）来解耦业务逻辑和数据库访问层，这样对于任务分工和代码开发维护带来了极大的便利。
简单的增删改查例子
package changsheng.logic;import changsheng.bean.People;import changsheng.dao.PeopleDAO;public class PeopleService {PeopleDAO dao = new PeopleDAO();public boolean addPeople(People people){//check the parameter of the people//code ...return dao.add(people);}public boolean delPeople(People people){//check the parameter of the people//code ...return dao.del(people);}public People queryPeople(People people){//check the parameter of the people//code ...return dao.query(people);}public boolean modifyPeople(People people){//check the parameter of the people//code ...return dao.modify(people);}}
通过上面的小例子可以看出通过引入facade模式隔离了数据库访问层与业务逻辑层。使业务逻辑在获取数据时根本不必知道数据该如何访问，简化了业务逻辑层的调用。 上面的例子中应该面向接口编程（即遵循DIP依赖倒转原则），另外PeopleDAO可以根据需求改写为单例，在此不再细述。
Applicability 适用范围? youwant to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, resultin more and smaller classes. This makes thesubsystem more reusable and easier to customize, but it also becomesharder to use for clients that don't need to customize it. A facade can provide asimple default view of the subsystem that is good enough for mostclients. Only clients needing more customizability will need to look beyond thefacade.? 你想为复杂的子系统提供一套简单的接口。子系统往往因为不断演化而变得越来越复杂。大多数模式在使用时，只会产生更多更小的类。使子系统更容易重用，更容易定制，但是他也会使那些不需要定制的用户变 得难以使用。Fa?ade模式可以为大多数客户提供一个简单易用的视图（一套接口）。而那些需要更多定制的用户可以跨过fa?ade提供的接口，而是用子系统内部的功能。
?there are many dependencies betweenclients and the implementation classes of an abstraction. Introduce a facade todecouple the subsystem from clients and other subsystems, thereby promotingsubsystem independence and portability.?客户程序与抽象类的实现部分之间存在着很大的依赖性。引入f a ca d e将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
?you want to layer your subsystems.Use a facade to define an entry point to each subsystem level. If subsystemsare dependent, then you can simplify the dependencies between them by makingthem communicate with each other solely through their facades.?当你需要构建一个层次结构的子系统时，使用f a c a d e模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过f a c a d e进行通讯，从而简化了它们之间的依赖关系。
structure 结构
example Compiler
Consequences 效果?Itshields clients from subsystem components, thereby reducing the number ofobjects that clients deal with and making the subsystem easier to use.?它屏蔽了客户与子系统，因此减少了客户端所需要类的数目，使子系统更容易使用。?Itpromotes weak coupling between the subsystem and its clients.?它减弱了客户与子系统之间的耦合关系。?Itdoesn't prevent applications from using subsystem classes if they need to. Thusyou can choose between ease of use and generality.
Related Patterns 相关模式
?AbstractFactory (3.1)模式可以与F a c a d e模式一起使用以提供一个接口，这一接口可用来以一种子系统独立的方式创建子系统对象。Abstract Factory也可以代替F a c a d e模式隐藏那些与平台相关的类。
?Mediator(5.5) 模式与F a c a d e模式的相似之处是，它抽象了一些已有的类的功能。然而，M e d i a t o r的目的是对同事之间的任意通讯进行抽象，通常集中不属于任何单个对象的功能。M e d i a t o r的同事对象知道中介者并与它通信，而不是直接与其他同类对象通信。相对而言，F a c a d e模式仅对子系统对象的接口进行抽象，从而使它们更容易使用；它并不定义新功能，子系统也不知道f a c a d e的存在。通常来讲，仅需要一个F a c a d e对象，因此F a c a d e对象通常属于Singleton (3.5)模式。
DAO
在开发中会经常对数据库中的数据进行查询或者修改，如果业务逻辑加入大量的JDBC应用代码必然会造成代码坏味道，业务逻辑与JDBC应用严重偶合在一起，会造成系统阅读困难，修改困难等。 这个时候在业务逻辑和数据库访问中间加上一层DAO—ata Acess Object）来解耦业务逻辑和数据库访问层，这样对于任务分工和代码开发维护带来了极大的便利。
简单的增删改查例子
package changsheng.logic;import changsheng.bean.People;import changsheng.dao.PeopleDAO;public class PeopleService {PeopleDAO dao = new PeopleDAO();public boolean addPeople(People people){//check the parameter of the people//code ...return dao.add(people);}public boolean delPeople(People people){//check the parameter of the people//code ...return dao.del(people);}public People queryPeople(People people){//check the parameter of the people//code ...return dao.query(people);}public boolean modifyPeople(People people){//check the parameter of the people//code ...return dao.modify(people);}}
通过上面的小例子可以看出通过引入facade模式隔离了数据库访问层与业务逻辑层。使业务逻辑在获取数据时根本不必知道数据该如何访问，简化了业务逻辑层的调用。 上面的例子中应该面向接口编程（即遵循DIP依赖倒转原则），另外PeopleDAO可以根据需求改写为单例，在此不再细述。
Related Patterns 相关模式
?AbstractFactory (3.1)模式可以与F a c a d e模式一起使用以提供一个接口，这一接口可用来以一种子系统独立的方式创建子系统对象。Abstract Factory也可以代替F a c a d e模式隐藏那些与平台相关的类。
?Mediator(5.5) 模式与F a c a d e模式的相似之处是，它抽象了一些已有的类的功能。然而，M e d i a t o r的目的是对同事之间的任意通讯进行抽象，通常集中不属于任何单个对象的功能。M e d i a t o r的同事对象知道中介者并与它通信，而不是直接与其他同类对象通信。相对而言，F a c a d e模式仅对子系统对象的接口进行抽象，从而使它们更容易使用；它并不定义新功能，子系统也不知道f a c a d e的存在。通常来讲，仅需要一个F a c a d e对象，因此F a c a d e对象通常属于Singleton (3.5)模式。
DAO
在开发中会经常对数据库中的数据进行查询或者修改，如果业务逻辑加入大量的JDBC应用代码必然会造成代码坏味道，业务逻辑与JDBC应用严重偶合在一起，会造成系统阅读困难，修改困难等。 这个时候在业务逻辑和数据库访问中间加上一层DAO—ata Acess Object）来解耦业务逻辑和数据库访问层，这样对于任务分工和代码开发维护带来了极大的便利。
简单的增删改查例子
package changsheng.logic;import changsheng.bean.People;import changsheng.dao.PeopleDAO;public class PeopleService {PeopleDAO dao = new PeopleDAO();public boolean addPeople(People people){//check the parameter of the people//code ...return dao.add(people);}public boolean delPeople(People people){//check the parameter of the people//code ...return dao.del(people);}public People queryPeople(People people){//check the parameter of the people//code ...return dao.query(people);}public boolean modifyPeople(People people){//check the parameter of the people//code ...return dao.modify(people);}}
通过上面的小例子可以看出通过引入facade模式隔离了数据库访问层与业务逻辑层。使业务逻辑在获取数据时根本不必知道数据该如何访问，简化了业务逻辑层的调用。 上面的例子中应该面向接口编程（即遵循DIP依赖倒转原则），另外PeopleDAO可以根据需求改写为单例，在此不再细述。
在开发中会经常对数据库中的数据进行查询或者修改，如果业务逻辑加入大量的JDBC应用代码必然会造成代码坏味道，业务逻辑与JDBC应用严重偶合在一起，会造成系统阅读困难，修改困难等。 这个时候在业务逻辑和数据库访问中间加上一层DAO—ata Acess Object）来解耦业务逻辑和数据库访问层，这样对于任务分工和代码开发维护带来了极大的便利。
简单的增删改查例子
package changsheng.logic;import changsheng.bean.People;import changsheng.dao.PeopleDAO;public class PeopleService {PeopleDAO dao = new PeopleDAO();public boolean addPeople(People people){//check the parameter of the people//code ...return dao.add(people);}public boolean delPeople(People people){//check the parameter of the people//code ...return dao.del(people);}public People queryPeople(People people){//check the parameter of the people//code ...return dao.query(people);}public boolean modifyPeople(People people){//check the parameter of the people//code ...return dao.modify(people);}}通过上面的小例子可以看出通过引入facade模式隔离了数据库访问层与业务逻辑层。使业务逻辑在获取数据时根本不必知道数据该如何访问，简化了业务逻辑层的调用。 上面的例子中应该面向接口编程（即遵循DIP依赖倒转原则），另外PeopleDAO可以根据需求改写为单例，在此不再细述。