The faade pattern

The purpose of the façade pattern is to provide an interface to a set of interfaces in a subsystem [GHJ95]. Using this pattern makes the objects included in the subsystem easier to use.

To explain the context in which the façade pattern can be used, let us refer again to an application that is based in a crop simulation model. The application will have a graphical user interface (GUI) that will allow users to enter the required initial data. The heart of the application is the crop simulation model that will run the simulation using the entries provided by the user. Most of the crop simulation models use a core of objects or components such as Weather, Soil, Plant, and SoilPlantAtmosphere. The simulation results may be used for purposes such as to display different graphics or maps or to create reports or other operations that are needed to satisfy user's requirements. The communication between the user interface and the crop simulation model is bidirectional; users will enter initial data and the simulation model will return the results of the simulation to the user's interface.

When environmental-based applications are developed, the most common approach is to strongly link the code needed for the user interface with the code representing the environmental model. This approach may allow for fast software development, as any object can be accessed by any other object anywhere, but it is not an optimal one, as it creates long-term problems related to code maintenance and reuse. Although the user interface and the environmental model exchange data between them and are part of the same application, they represent two separate parts of the system and therefore should be designed to function independently. Having strongly coupled the user interface with objects/components such as Soil, Weather, and Plant makes the system hard to maintain and difficult to reuse. In such a highly coupled system, no part of it can be reused or easily modified.

This kind of problem can be solved using the façade pattern. The essence of this pattern is to provide a unique point of communication between an object and the surrounding environment. Figure 7-18 shows the class diagram for the façade pattern in general.

As shown in this figure, communication between client objects and a group of other objects is filtered by the FacadeClass. Therefore, FacadeClass should be provided with the right behavior in order to represent the rest of the objects in communication with the surrounding environment.

Figure 7-18. Class diagram for the facade pattern.

Figure 7-19 shows the class diagram for the crop simulation example. It is important to note that the associations between Simulator and the GUI classes are bidirectional. Simulator controls all the communication between the GUI classes and crop simulation objects.

Although the FacadeClass controls the communication between clients and a group of classes implementing some abstraction, it is not necessary that the FacadeClass be a rigorous barrier between them. In some cases it is advised to let clients have access to particular objects behind the façade. In these cases, the FacadeClass should be provided with the behavior that makes its objects accessible to clients. Figure 7-19 shows that Simulator is provided with operations that can make available to GUI objects any of the Plant, Weather, Soil, or PlantSoilAtmosphere objects.




0 0

Post a comment