UML软件工程组织

 

 

Java设计模式之外观模式研究
 
作者: stoneWindow 翻译 出处: Java研究组织
 

外观模式(Facade pattern)涉及到子系统的一些类。所谓子系统,是为提供一系列相关的特征(功能)而紧密关联的一组类。例如,一个Account类、Address类和CreditCard类相互关联,成为子系统的一部分,提供在线客户的特征。

在真实的应用系统中,一个子系统可能由很多类组成。子系统的客户为了它们的需要,需要和子系统中的一些类进行交互。客户和子系统的类进行直接的交互会导致客户端对象和子系统(Figure1)之间高度耦合。任何的类似于对子系统中类的接口的修改,会对依赖于它的所有的客户类造成影响。

  
Figure1: Client Interaction with Subsystem Classes before Applying the Facade Pattern

外观模式(Facade pattern)很适用于在上述情况。外观模式(Facade pattern)为子系统提供了一个更高层次、更简单的接口,从而降低了子系统的复杂度和依赖。这使得子系统更易于使用和管理。

外观是一个能为子系统和客户提供简单接口的类。当正确的应用外观,客户不再直接和子系统中的类交互,而是与外观交互。外观承担与子系统中类交互的责任。实际上,外观是子系统与客户的接口,这样外观模式降低了子系统和客户的耦合度(Figure2).

  
Figure2: Client Interaction with Subsystem Classes after Applying the Facade Pattern

从Figure2中我们可以看到:外观对象隔离了客户和子系统对象,从而降低了耦合度。当子系统中的类进行改变时,客户端不会像以前一样受到影响。

尽管客户使用由外观提供的简单接口,但是当需要的时候,客户端还是可以视外观不存在,直接访问子系统中的底层次的接口。这种情况下,它们之间的依赖/耦合度和原来一样。

例子:

让我们建立一个应用:

(1) 接受客户的详细资料(账户、地址和信用卡信息)

(2) 验证输入的信息

(3) 保存输入的信息到相应的文件中。

这个应用有三个类:Account、Address和CreditCard。每一个类都有自己的验证和保存数据的方法。

Listing1: AccountClass

public class Account {
 String firstName;
 String lastName;
 final String ACCOUNT_DATA_FILE = "AccountData.txt";
 public Account(String fname, String lname) {
  firstName = fname;
  lastName = lname;
 }
 public boolean isValid() {
  /*
  Let's go with simpler validation
  here to keep the example simpler.
  */
  …
  …
 }
 public boolean save() {
  FileUtil futil = new FileUtil();
  String dataLine = getLastName() + ”," + getFirstName();
  return futil.writeToFile(ACCOUNT_DATA_FILE, dataLine,true, true);
 }
 public String getFirstName() {
  return firstName;
 }
 public String getLastName() {
  return lastName;
 }
}

Listing2: Address Class

public class Address {
 String address;
 String city;
 String state;
 final String ADDRESS_DATA_FILE = "Address.txt";
 public Address(String add, String cty, String st) {
  address = add;
  city = cty;
  state = st;
 }
 public boolean isValid() {
  /*
  The address validation algorithm
  could be complex in real-world
  applications.
  Let's go with simpler validation
  here to keep the example simpler.
  */
  if (getState().trim().length() < 2)
   return false;
  return true;
 }
 public boolean save() {
  FileUtil futil = new FileUtil();
  String dataLine = getAddress() + ”," + getCity() + ”," + getState();
  return futil.writeToFile(ADDRESS_DATA_FILE, dataLine,true, true);
 }
 public String getAddress() {
  return address;
 }
 public String getCity() {
  return city;
 }
 public String getState() {
  return state;
 }
}

Listing3: CreditCard Class

public class CreditCard {
 String cardType;
 String cardNumber;
 String cardExpDate;
 final String CC_DATA_FILE = "CC.txt";
 public CreditCard(String ccType, String ccNumber,
 String ccExpDate) {
  cardType = ccType;
  cardNumber = ccNumber;
  cardExpDate = ccExpDate;
 }
 public boolean isValid() {
  /*
  Let's go with simpler validation
  here to keep the example simpler.
  */
  if (getCardType().equals(AccountManager.VISA)) {
   return (getCardNumber().trim().length() == 16);
  }
  if (getCardType().equals(AccountManager.DISCOVER)) {
   return (getCardNumber().trim().length() == 15);
  }
  if (getCardType().equals(AccountManager.MASTER)) {
   return (getCardNumber().trim().length() == 16);
  }
  return false;
 }
 public boolean save() {
  FileUtil futil = new FileUtil();
  String dataLine = getCardType() + ,”" + getCardNumber() + ”," + getCardExpDate();
  return futil.writeToFile(CC_DATA_FILE, dataLine, true, true);
 }
 public String getCardType() {
  return cardType;
 }
 public String getCardNumber() {
  return cardNumber;
 }
 public String getCardExpDate() {
  return cardExpDate;
 }
}

  
Figure3: Subsystem Classes to Provide the Necessary Functionality to Validate and Save the Customer Data

让我们建立一个客户AccountManager,它提供用户输入数据的用户界面。

Listing4: Client AccountManager Class

public class AccountManager extends JFrame {
 public static final String newline = "\n";
 public static final String VALIDATE_SAVE = "Validate & Save";
 …
 …
 public AccountManager() {
  super(" Facade Pattern - Example ");
  cmbCardType = new JComboBox();
  cmbCardType.addItem(AccountManager.VISA);
  cmbCardType.addItem(AccountManager.MASTER);
  cmbCardType.addItem(AccountManager.DISCOVER);
  …
  …
  //Create buttons
  JButton validateSaveButton = new JButton(AccountManager.VALIDATE_SAVE);
  …
  …
 }
 public String getFirstName() {
  return txtFirstName.getText();
 }
 …
 …
}//End of class AccountManager

当客户AccountManage运行的时候,展示的用户接口如下:

  
Figure4: User Interface to Enter the Customer Data

为了验证和保存输入的数据,客户AccountManager需要:

(1) 建立Account、Address和CreditCard对象。

(2) 用这些对象验证输入的数据

(3) 用这些对象保存输入的数据。

下面是对象间的交互顺序图:

 
Figure5: How a Client Would Normally Interact (Directly) with Subsystem Classes to Validate and Save the Customer Data

在这个例子中应用外观模式是一个很好的设计,它可以降低客户和子系统组件(Address、Account和CreditCard)之间的耦合度。应用外观模式,让我们定义一个外观类CustomerFacade (Figure6 and Listing5)。它为由客户数据处理类(Address、Account和CreditCard)所组成的子系统提供一个高层次的、简单的接口。

CustomerFacade
address:String
city:String
state:String
cardType:String
cardNumber:String
cardExpDate:String
fname:String
lname:String
setAddress(inAddress:String)
setCity(inCity:String)
setState(inState:String)
setCardType(inCardType:String)
setCardNumber(inCardNumber:String)
setCardExpDate(inCardExpDate:String)
setFName(inFName:String)
setLName(inLName:String)
saveCustomerData()

  
Figure6: Facade Class to Be Used by the Client in the Revised Design

Listing5: CustomerFacade Class

public class CustomerFacade {
 private String address;
 private String city;
 private String state;
 private String cardType;
 private String cardNumber;
 private String cardExpDate;
 private String fname;
 private String lname;
 public void setAddress(String inAddress) {
  address = inAddress;
 }
 public void setCity(String inCity) {
  city = inCity;
 }
 public void setState(String inState) {
  state = inState;
 }
 public void setFName(String inFName) {
  fname = inFName;
 }
 public void setLName(String inLName) {
  lname = inLName;
 }
 public void setCardType(String inCardType) {
  cardType = inCardType;
 }
 public void setCardNumber(String inCardNumber) {
  cardNumber = inCardNumber;
 }
 public void setCardExpDate(String inCardExpDate) {
  cardExpDate = inCardExpDate;
 }
 public boolean saveCustomerData() {
  Address objAddress;
  Account objAccount;
  CreditCard objCreditCard;
  /*
   client is transparent from the following
   set of subsystem related operations.
  */
  boolean validData = true;
  String errorMessage = "";
  objAccount = new Account(fname, lname);
  if (objAccount.isValid() == false) {
   validData = false;
   errorMessage = "Invalid FirstName/LastName";
  }
  objAddress = new Address(address, city, state);
  if (objAddress.isValid() == false) {
   validData = false;
   errorMessage = "Invalid Address/City/State";
  }
  objCreditCard = new CreditCard(cardType, cardNumber, cardExpDate);
  if (objCreditCard.isValid() == false) {
   validData = false;
   errorMessage = "Invalid CreditCard Info";
  }
  if (!validData) {
   System.out.println(errorMessage);
   return false;
  }
  if (objAddress.save() && objAccount.save() && objCreditCard.save()) {
   return true;
  } else {
   return false;
  }
 }
}

CustomerFacade类以saveCustomData方法的形式提供了业务层次上的服务。客户AccountManager不是直接和子系统的每一个组件交互,而是使用了由CustomFacade对象提供的验证和保存客户数据的更高层次、更简单的接口(Figure7).

 
Figure7: Class Association with the Fa?ade Class in Place 。

在新的设计中,为了验证和保存客户数据,客户需要:

(1) 建立或获得外观对象CustomFacade的一个实例。

(2) 传递数据给CustomFacade实例进行验证和保存。

(3) 调用CustomFacade实例上的saveCustomData方法。

CustomFacade处理创建子系统中必要的对象并且调用这些对象上相应的验证、保存客户数据的方法这些细节问题。客户不再需要直接访问任何的子系统中的对象。

Figure8展示了新的设计的消息流图:

 
Figure 22.8: In the Revised Design, Clients Interact with the Fa?ade Instance to Interface with the Subsystem

重要提示

下面是应用外观模式的注意事项:

(1) 在设计外观时,不需要增加额外的功能。

(2) 不要从外观方法中返回子系统中的组件给客户。例如:有一个下面的方法:

CreditCard getCreditCard()

会报漏子系统的细节给客户。应用就不能从应用外观模式中取得最大的好处。

(3)应用外观的目的是提供一个高层次的接口。因此,外观方法最适合提供特定的高层次的业务服务,而不是进行底层次的单独的业务执行。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号