本文聚焦于Facade模式的探讨。通过实例分析，解释了Facade如何在软件架构中提供一个统一接口，简化复杂子系统的使用。文章还讨论了Facade在实际世界中的应用，如操作系统的简化接口和建筑外观的简化设计。最后，通过Java代码示例展示了如何在实际项目中应用Facade模式，以提高代码的可读性和维护性。
This article will focus on the Facade pattern. So far in our design patterns we've already looked at the Observer and Adapterpatterns. Facade has some similarities with the Adapter, so it's a logical next step in our series.
Facades in the Real World
Facades are all around us in the real world. Operating systems are one such example - you don't see all the inner workings of your computer, but the OS provides a simplified interface to use the machine. Buildings also have a facade - the exterior of the building. Wikipedia gives us a nice link between software architecture and standard architecture:
In architecture, the facade of a building is often the most important from a design standpoint, as it sets the tone for the rest of the building
So, in a nutshell, a Facade aims to make things look cleaner and more appealling.
The Facade Pattern
Like the Adapter pattern, Facade is known as a structural pattern, as it's used to identifying a simple way to realize relationships between entities. The definition of Facade provided in the original Gang of Four book on Design Patterns states:
Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.
The diagram definition of the Facade pattern is quite simple - all you're really doing is insulating client from the subsystem:
Like the adapter pattern, the Facade can be used to hide the inner workings of a third party library, or some legacy code. All that the client needs to do is interact with the Facade, and not the subsystem that it is encompassing.
The following sequence diagram illustrates how the pattern is used by a client:
Where Would I Use This Pattern?
As the concept behind facade is to simplify an interface, service oriented architectures make use of the facade pattern. For example, in web services, one web service might provide access to a number of smaller services that have been hidden from the caller by the facade. Similarly, a typical pattern in OSGi bundles is to provide an interface package that is exposed to users of the bundle. All other packages are hidden from the user.
So How Does It Work In Java?
Let's put together a simple example in Java code to illustrate the pattern. Let's take a travel agent site for example, that allows you to book hotels and flights. We have a HotelBooker:
01.
public class HotelBooker
02.
{
03.
04.
public ArrayList<Hotel> getHotelNamesFor(Date from, Date to)
05.
{
06.
//returns hotels available in the particular date range
07.
08.
}
09.
10.
}
And a FlightBooker:
01.
public class FlightBooker
02.
{
03.
04.
public ArrayList<Flight> getFlightsFor(Date from, Date to)
05.
{
06.
//returns flights available in the particular date range
07.
08.
}
09.
10.
}
Both of these have Hotel and Flight datatypes, which the client has knowledge about. They could be provided in the same package as the Facade for example.
The TravelFacade class allows the user to get their Hotel and Flight information in one call:
01.
public class TravelFacade
02.
{
03.
04.
private HotelBooker hotelBooker;
05.
private FlightBooker flightBooker;
06.
07.
public void getFlightsAndHotels(Date from, Data to)
08.
{
09.
ArrayList<Flight> flights = flightBooker.getFlightsFor(from, to);
10.
ArrayList<Hotel> hotels = hotelBooker.getHotelsFor(from, to);
11.
12.
//process and return
13.
14.
}
15.
16.
}
All that the client needs to worry about is the Facade class:
01.
public class Client
02.
{
03.
04.
public static void main(String[] args)
05.
{
06.
TravelFacade facade = new TravelFacade();
07.
facade.getFlightsAndHotels(from, to);
08.
}
09.
}
As you can see, it's just a simple approach to encapsulating data.
Watch Out for the Downsides
By introducing the Facade into your code, you will be hardwiring subsystems into the Facade. This is fine if the subsystem never changes, but if it does, your Facade could be broken. Therefore, developers working on the subsystem should be made aware of any Facade around their code.Next Up
We'll get to the Singleton pattern next week.
扫一扫
到【灌水乐园】发言
Comments
Mateusz Mrozewski replied on Sat, 2010/02/13 - 5:23am
In the second listing the class name should be FlightBooker.
Thank you for the series, it's excellent. It will be very valuable for anyone who wants to learn design patterns. Keep going :)
Vedhas Pitkar replied on Sun, 2010/02/14 - 11:54pm
James Sugrue replied on Mon, 2010/02/15 - 2:46am
in response to: Vedhas Pitkar
Thanks for the comments. I'll make sure to add in the differences in the future patterns, and will edit the existing articles in the series soon to illustrate the differences.
Sriram Varadharajan replied on Mon, 2010/02/15 - 8:48am
Bogdan Marian replied on Mon, 2010/02/15 - 9:06am
I really appreciate your effort you put in describing the GOF design patterns.
I can hardly wait for the next articles.
Well done, James.
prashant jalasutram replied on Tue, 2010/02/16 - 5:53am
Mladen Girazovski replied on Tue, 2010/02/16 - 2:38pm
in response to: Sriram Varadharajan
You're kidding, right?
Sudhakar Ramasamy replied on Wed, 2010/03/17 - 10:48pm
JavaOnZone Neon replied on Thu, 2011/07/21 - 2:40pm
nilesh gule replied on Mon, 2012/07/16 - 9:59am
Nicely depicted using hotels and flights. This is one of the best example I have seen for Facade pattern. I recently posted about C# implementation of Facade using Home Loan as an example.
http://www.nileshgule.com/2012/07/facade-design-pattern.html