Java外观模式(Facade)

来源：互联网发布：常平淘宝培训编辑：程序博客网时间：2024/05/16 16:05

许多开源的框架中都充分的利用了设计模式这一概念，Struts典型的MVC模式的化身，Spring是工厂模式和单例模式的充分体现。在项目开发中，能充分利用设计模式的思想来考虑问题，来解决问题，来通过代码去实现。不但可以提高代码的质量，对程序的扩展，重用带来很大方便。其实我们项目中用设计模式编程就是加了一个封装层，减少客户必须处理的对象的数量。
在设计模式中一般都遵循这样的原则：
(1)按接口编程。
(2)尽量用聚合代替继承。
(3)找出变化并封装之。
上面主要讲了一些设计模式的作用和原则。接下来我要讲的是在实际项目中应用的比较多的其中一个模式----->门面模式（Facade），有的叫正面，外观模式，其实都是一个意识，都指的这个模式。它也是美国著名的四人帮（GOF）写的23种模式之一。
简单的理解：我们需要用一种比原有的方法更简单的方法与系统交互，或者说，我们需要以一种特殊的方式使用系统。主要是为子系统中的一组接口提供一个统一的接口。Facade模式定义了一个更高的接口，使子系统更加容易使用。它的意图要求一个一致的高层接口。
我简单的用代码方式表现出来。我写的都是一些伪代码。主要是来讲清Facade的应用。
以简单的登录为例：
我们一般都会写一个DAO层，主要封装了数据库里增，删，该，查作用。

我们一般会写一个接口：简单声明一个方法。根据用户名和密码来从数据库中查找是否存在。

[java] view plaincopyprint?

public interface UserDAO {
public abstract List findByUserName(Object userName,Object passWord);
public abstract List findByUserName(Object userName);
public abstract List findByUserPassword(Object userPassword);
public abstract List findByUserPortraitUrl(Object userPortraitUrl);
public abstract List findByEmail(Object email);
public abstract List findByUrl(Object url);
public abstract List findByRole(Object role);
}

public interface UserDAO {   public abstract List findByUserName(Object userName,Object passWord); public abstract List findByUserName(Object userName); public abstract List findByUserPassword(Object userPassword); public abstract List findByUserPortraitUrl(Object userPortraitUrl); public abstract List findByEmail(Object email); public abstract List findByUrl(Object url); public abstract List findByRole(Object role);}

然后再写一个接口的实现：

[java] view plaincopyprint?

public class UserDAOImpimplements UserDAO {
public List findByUserName(Object userName,Object passWord){
//判断用户是否存在。存在返回一个list,反之为null.
}
public List findByUserName(Object userName){
//实现
}
public List findByUserPassword(Object userPassword){
//实现
}
public List findByUserPortraitUrl(Object userPortraitUrl){
//实现
}
public List findByEmail(Object email){
//实现
}
public List findByUrl(Object url){
//实现
}
public List findByRole(Object role){
//实现
}
}

public class UserDAOImp implements UserDAO {         public  List findByUserName(Object userName,Object passWord){         //判断用户是否存在。存在返回一个list,反之为null. }  public List findByUserName(Object userName){    //实现} public  List findByUserPassword(Object userPassword){     //实现} public   List findByUserPortraitUrl(Object userPortraitUrl){     //实现} public  List findByEmail(Object email){     //实现} public  List findByUrl(Object url){     //实现} public  List findByRole(Object role){     //实现}}

我们一般应用门面模式是在业务层。我们在写一个业务方法：和上面一样先声明一个接口。

[java] view plaincopyprint?

public interface UserService{
public boolean login(Stirng userName,String passWord);
}

public interface UserService{      public boolean login(Stirng userName,String passWord);}

在写一个业务接口的实现。

[java] view plaincopyprint?

public class UserServiceImpimplements UserService{
private UserDAO userDao;
public void setUserDAO(UserDAO userDao){
this.userDao = userDao;
}
public UserDAO getUserDao(){
return userDao;
}
public boolean login(Stirng userName,String passWord){
if(userDao.findByUserName(userName,passWord)!=null){
//合法用户，登录成功。
}else{
//登录失败。
}
}
}

public class UserServiceImp implements UserService{     private UserDAO userDao;     public void setUserDAO(UserDAO userDao){             this.userDao = userDao; }     public UserDAO getUserDao(){               return userDao;              }     public boolean login(Stirng userName,String passWord){            if(userDao.findByUserName(userName,passWord)!=null){       //合法用户，登录成功。  }else{         //登录失败。 }  }}

我们可以看到我们在业务层中对DAO层又进行了一层封装。这就是Facade模式的简单应用的场合，有人可能会想为什么不直接调用DAO层呢？因为在实际的应用中，也许DAO中的方法太多，而我们实际用到的方法只是其中的一个或几个，所有把业务中用到的方法在提出出来封装处理，对调用者来说也很方便，它不会直接接触到DAO，我们把DAO封装在Service层中是为了让各个层职责分明。这样做还有一个用处，我们可能还会对用户的登录信息进行记录，这是我们就可以在Service层中处理，以及事务等。之所以把它封装在业务层中，避免了用户直接对数据库DAO层的直接操作，对用户来说是透明的。这样就简单了实现了松耦合。
Facade模式可以应用于：
<1>不需要使用一个复杂系统的所有功能，而且可以创建一个新的类，包含访问系统的所用规则。如果只需要使用系统的部分功能，那么你为新类创建的API将比原有系统的API简单的多。
<2>希望封装或者隐藏原系统。
<3>希望使用原系统的功能，而且还希望增加一些附件功能。
Facade模式的几个要点
• 从客户程序的角度来看， Facade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Façade接口的变化。
• Façade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Façade很多时候更是一种架构设计模式。
• 注意区分Façade模式、Adapter模式、Bridge模式与Decorator模式。Façade模式注重简化接口，Adapter模式注重转换接口，Bridge模式注重分离接口（抽象）与其实现，Decorator模式注重稳定接口的前提下为对象扩展功能。

0 0