When looking for suitable strate­gies to simplify complex software, one in­evitably en­coun­ters the facade design pattern or simply facade pattern. Much like the decorator pattern or the composite pattern, it belongs to the category of struc­tur­al patterns of the so-called GoF design patterns (the ab­bre­vi­a­tion “GoF” stands for “Gang of Four”), which have had a decisive influence on software design since pub­li­ca­tion in 1994.

In this article, we’ll show you what the facade pattern is and how it helps de­vel­op­ers equalize sub-systems.

What is the facade pattern

The facade design pattern is one of the 23 GoF design patterns, which were published in 1994 by authors Erich Gamma, Ralph Johnson, Richard Helm, and John Vlissides in “Design Patterns: Elements of Reusable Object-Oriented Software” as guidance for software de­vel­op­ers. In general, these patterns aim to simplify the creation of flexible, reusable software. The facade pattern defines a sample solution for the simple merging of different in­ter­faces in complex systems. A universal facade class, which also functions as an interface, delegates important func­tion­al­i­ties of the software to the re­spec­tive sub-systems in order to make handling the various sub-com­po­nents of a program as simple as possible.

What problems does the facade pattern address?

Clients that access a complex sub-system refer directly to a large number of objects with com­plete­ly different interfaces or are dependent on these objects. This makes the im­ple­men­ta­tion, adap­ta­tion, testing, and reuse of the clients par­tic­u­lar­ly difficult for de­vel­op­ers. This is where the facade design pattern can be useful.

The facade design pattern defines a central facade object that:

  • im­ple­ments a universal interface for the various in­ter­faces of the sub-system(s).
  • and (if necessary) can perform ad­di­tion­al functions before or after for­ward­ing a client request.

As an in­ter­me­di­ary, the facade object ensures that access and com­mu­ni­ca­tion with the in­di­vid­ual com­po­nents of a subsystem are sim­pli­fied and direct de­pen­dence on these com­po­nents is minimized. It delegates the client calls so clients don’t need to know the classes or their re­la­tion­ships and de­pen­den­cies.

B1Y8fcYrz5o.jpg To display this video, third-party cookies are required. You can access and change your cookie settings here.

Facade pattern: UML class diagram of the design pattern

The facade or the facade class is the decisive struc­tur­ing unit of the facade pattern. In other words, its im­ple­men­ta­tion and prepa­ra­tion is the fun­da­men­tal task for de­vel­op­ers looking to simplify their complex software by using this handy design pattern. Once im­ple­ment­ed, the client objects com­mu­ni­cate with the facade class, which in this new system is the only instance on which the clients are directly dependent.

The following UML diagram il­lus­trates the in­ter­ac­tion of clients, facade, and sub-system classes according to the facade pattern.

Image: Facade pattern: UML class diagram
The number of four class packages in the UML diagram is exemplary – the­o­ret­i­cal­ly, any number of classes in the sub-system can be con­trolled via the facade class.

Facade pattern: ad­van­tages and dis­ad­van­tages

The ad­van­tages of the facade design pattern are obvious: The facade “hides” the un­der­ly­ing software sub-systems and thereby reduces the com­plex­i­ty of these systems. In addition, the approach promotes the principle of loose coupling. Due to the low degree of in­ter­de­pen­dence of the in­di­vid­ual com­po­nents, changes (mod­i­fi­ca­tions, main­te­nance) are con­ve­nient and possible at any time. Because of loose coupling a sub-system is easier to expand.

Note

If clients are dependent on direct access to certain classes of the sub-system, this can also be granted in the facade pattern model. In this case, only the vis­i­bil­i­ty of the sub-system needs to be pro­grammed so that a client can bypass the facade if necessary.

However, the use of the facade design pattern has some dis­ad­van­tages. Because of its central role, the im­ple­men­ta­tion of a facade is a tedious and com­pli­cat­ed task, es­pe­cial­ly if it has to be inserted into existing code. In general, the in­stal­la­tion of a facade interface requires an ad­di­tion­al in­di­rec­tion stage, that in turn increases computing time for method and function calls, memory access, etc. Finally, the facade pattern also harbors the risk that the software becomes too dependent on the central master interface.

Ad­van­tages Dis­ad­van­tages
Minimizes com­plex­i­ty of sub-systems Complex im­ple­men­ta­tion (es­pe­cial­ly with existing code)
Aids principle of loose coupling Approach is coupled to an ad­di­tion­al level of in­di­rec­tion
Software becomes more flexible and easily ex­pand­able High degree of de­pen­dence at facade interface

Typical use cases of the facade design pattern

The prop­er­ties of the facade design make it an in­ter­est­ing pattern for several ap­pli­ca­tion scenarios. Above all, there is the desire for a uniform interface to access complex sub-systems or any number of objects. A facade promises to simplify things here. That’s why the use of the facade pattern strategy should play a major role when planning a project.

Another typical ap­pli­ca­tion is software in which the de­pen­den­cy between clients and un­der­ly­ing sub­sys­tems is to be minimized.

Finally, the facade pattern is a useful approach to plan software projects that have multiple layers. The facades act as com­mu­ni­ca­tion in­ter­faces between the in­di­vid­ual layers, in­creas­ing flex­i­bil­i­ty and the pos­si­bil­i­ty of extension and adap­ta­tion of com­po­nents.

Practical example of facade pattern im­ple­men­ta­tion

The facade design pattern is connected to specific pro­gram­ming languages. The pattern is typically used with C++, C#, JavaScript, Java, PHP, and Python. The following facade pattern example is based on Java and taken from tu­to­ri­al­s­point.com.

In this example, a uni­ver­sal­ly ap­plic­a­ble interface “Shape” is to be defined for objects that represent a geometric form. In addition, concrete classes are generated which implement the interface as well as facade classes called “Shape­Mak­er”, which are re­spon­si­ble for del­e­gat­ing client queries.

First, we create the interface Shape.java using the following code:

public interface Shape {
	void draw();
}

Secondly, three concrete classes are created that implement the interface: Rectangle.java (class for rectangle objects), Square.java (class for square objects), and Circle.java (class for round objects).

public class Rectangle implements Shape {
	@Override
	public void draw() {
		System.out.println("Rectangle::draw()");
	}
}
public class Square implements Shape {
	@Override
	public void draw() {
		System.out.println("Rectangle::draw()");
	}
}
public class Circle implements Shape {
	@Override
	public void draw() {
		System.out.println("Rectangle::draw()");
	}
}

Finally, the facade class ShapeMaker is in­te­grat­ed into the code which will be called upon by the clients to create the different shapes:

public class ShapeMaker {
	private Shape circle;
	private Shape rectangle;
	private Shape square;
	public ShapeMaker() {
		circle = new Circle();
		rectangle = new Rectangle();
		square = new Square();
	}
	public void drawCircle(){
		circle.draw();
	}
	public void drawRectangle(){
		rectangle.draw();
	}
	public void drawSquare(){
		square.draw();
	}
}
Go to Main Menu