<table align="center" border="0" width="90%"> <tr> <td>
500)this.style.width=500;">
Figure1: Client Interaction with Subsystem Classes before Applying the Facade Pattern </td> </tr>
</table>
Figure1: Client Interaction with Subsystem Classes before Applying the Facade Pattern </td> </tr>
外观模式（Facade pattern）很适用于在上述情况。外观模式（Facade pattern）为子系统提供了一个更高层次、更简单的接口，从而降低了子系统的复杂度和依赖。这使得子系统更易于使用和管理。
外观是一个能为子系统和客户提供简单接口的类。当正确的应用外观，客户不再直接和子系统中的类交互，而是与外观交互。外观承担与子系统中类交互的责任。实际上，外观是子系统与客户的接口，这样外观模式降低了子系统和客户的耦合度(Figure2).
<table align="center" border="0" width="90%"> <tr> <td> 500)this.style.width=500;">
Figure2: Client Interaction with Subsystem Classes after Applying the Facade Pattern </td> </tr> </table>
从Figure2中我们可以看到：外观对象隔离了客户和子系统对象，从而降低了耦合度。当子系统中的类进行改变时，客户端不会像以前一样受到影响。
尽管客户使用由外观提供的简单接口，但是当需要的时候，客户端还是可以视外观不存在，直接访问子系统中的底层次的接口。这种情况下，它们之间的依赖/耦合度和原来一样。
例子：
让我们建立一个应用：
（1） 接受客户的详细资料（账户、地址和信用卡信息）
（2） 验证输入的信息
（3） 保存输入的信息到相应的文件中。
这个应用有三个类：Account、Address和CreditCard。每一个类都有自己的验证和保存数据的方法。
Listing1: AccountClass
<table align="center" bgcolor="#e3e3e3" border="1" bordercolor="#cccccc" width="90%"> <tr> <td>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;
}
} </td> </tr> </table>
Listing2: Address Class
<table align="center" bgcolor="#e3e3e3" border="1" bordercolor="#cccccc" width="90%"> <tr> <td>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;
}
} </td> </tr> </table>
Listing3: CreditCard Class
<table align="center" bgcolor="#e3e3e3" border="1" bordercolor="#cccccc" width="90%"> <tr> <td>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;
}
} </td> </tr> </table>
<table align="center" border="0" width="90%"> <tr> <td> 500)this.style.width=500;">
Figure3: Subsystem Classes to Provide the Necessary Functionality to Validate and Save the Customer Data </td> </tr> </table>