Facade Pattern#

The Facade Pattern, also known as the "Facade Pattern", is an object structural pattern. Communication between the outside and a subsystem must go through a unified facade object, providing a consistent interface for a set of interfaces in the subsystem. The facade pattern defines a high-level interface that makes the subsystem easier to use. In Js, the Facade Pattern is often used to solve browser compatibility issues.

Description#

According to the Single Responsibility Principle, dividing a system into several subsystems in software is advantageous in reducing the overall complexity of the system. A common design goal is to minimize communication and interdependence between subsystems, and one way to achieve this goal is to introduce a facade object, which provides a simple and single entry point for subsystem access. The Facade Pattern also embodies the Law of Demeter, reducing the complexity of the original system by introducing a new facade class, while reducing the coupling between client classes and subsystem classes. The Facade Pattern also requires external communication with a subsystem to be done through a unified facade object. The facade class separates the complexity of the client from the internal subsystem, reducing the need for clients to interact with many objects inside the subsystem, thus reducing the complexity of the system.

Pattern Structure#

• Facade: Facade role.
• SubSystem: Subsystem role.

Advantages#

• It shields clients from the subsystem components, reducing the number of objects the client has to deal with and making it easier to use the subsystem. By introducing the Facade Pattern, client code becomes very simple and associated objects are also few.
• It achieves a loosely coupled relationship between the subsystem and the client, so that changes in the subsystem components do not affect the client classes that call them, and only the facade class needs to be adjusted.
• It reduces compilation dependencies in large software systems and simplifies the process of porting systems between different platforms, because compiling a subsystem generally does not require compiling all other subsystems. A modification to one subsystem has no impact on other subsystems, and internal changes in the subsystem also do not affect the facade object.
• It only provides a unified entry point to access the subsystem, without affecting direct use of the subsystem class by the user.

Disadvantages#

• It cannot effectively restrict client use of subsystem classes. If there are too many restrictions on client access to subsystem classes, it reduces variability and flexibility.
• Without introducing an abstract facade class, adding a new subsystem may require modification of the facade class or client-side source code, violating the open-closed principle.

Implementation#

/* 
 * Register element events, the addEvent function serves as the facade role, treating various browsers as subsystem roles 
 * @param element [required] the element to bind
 * @param type [required] event type
 * @param fn [required] callback function
 */
function addEvent(element, type, fn) {
    if (element.addEventListener) { // DOM2 event support for addEventListener method
        element.addEventListener(type, fn, false)
    } else if (element.attachEvent) { // attachEvent method support
        element.attachEvent("on" + type, fn)
    } else {
        element["on" + type] = fn // For browsers that do not support either, use DOM0 event binding
    }
}

Daily Question#

References#