En re­cher­chant des stra­té­gies ap­pro­priées pour sim­pli­fier des logiciels complexes, on tombe iné­vi­ta­ble­ment sur le design pattern facade (patron de con­cep­tion de façade en français) ou patron de façade pour faire court. Avec d’autres modèles comme le pattern decorator ou le pattern composite, il ap­par­tient à la catégorie des patrons de structure des patrons de con­cep­tion du « GoF » (pour « Gang of Four ») qui ont influencé de manière décisive la con­cep­tion de logiciels depuis leur pu­bli­ca­tion en 1994.

Vous ap­pren­drez dans les pa­ra­graphes suivants ce qu’est exac­te­ment le patron de façade et comment il aide les dé­ve­lop­peurs à équi­li­brer les sous-systèmes.

Qu’est-ce que le facade pattern ?

Le patron de façade est un des 23 patrons de con­cep­tion pour le dé­ve­lop­pe­ment de logiciels publiés en 1994 par Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides (connus sous le nom de GOF pour « Gang of Four ») dans « Design Patterns : Elements of Reusable Object-Oriented Software ». Fidèle au principe général de ces patrons visant à sim­pli­fier la création de logiciels flexibles et réu­ti­li­sables, le facade pattern propose une solution type pour fusionner fa­ci­le­ment dif­fé­rentes in­ter­faces dans des systèmes complexes. Une classe façade uni­ver­selle, qui fonc­tionne également comme une interface, délègue des fonc­tion­na­li­tés im­por­tantes du logiciel aux sous-systèmes res­pec­tifs afin de rendre le maniement des dif­fé­rents sous-com­po­sants d’un programme aussi simple que possible.

Pour quels problèmes le facade pattern est-il une solution ?

Les clients qui ont accès à un sous-système complexe doivent di­rec­te­ment faire face à une multitude d’objets ayant des in­ter­faces com­plè­te­ment dif­fé­rentes ou dépendent de ces objets. Cela rend l’im­plé­men­ta­tion, la per­son­na­li­sa­tion, les tests et la réu­ti­li­sa­tion des clients par­ti­cu­liè­re­ment dif­fi­ciles pour le dé­ve­lop­peur. C’est là que patron de façade in­ter­vient.

Le facade pattern prévoit la dé­fi­ni­tion d’un objet de façade central (également appelé « façade ») qui :

  • im­plé­mente une interface uni­ver­selle pour les dif­fé­rentes in­ter­faces du ou des sous-systèmes.
  • et peut exécuter (si né­ces­saire) des fonctions sup­plé­men­taires avant ou après la trans­mis­sion d’une demande du client.

En tant qu’in­ter­mé­diaire, l’objet façade garantit que l’accès ou la com­mu­ni­ca­tion avec les dif­fé­rents com­po­sants d’un sous-système est simplifié, réduisant ainsi la dé­pen­dance directe de ces com­po­sants au minimum. Il délègue les appels des clients afin que ceux-ci n’aient pas besoin de connaître les classes ou leurs relations et dé­pen­dances.

B1Y8fcYrz5o.jpg Pour afficher cette vidéo, des cookies de tiers sont nécessaires. Vous pouvez consulter et modifier vos paramètres de cookies ici.

Facade pattern : re­pré­sen­ta­tion graphique (UML)

La façade ou classe façade est l’unité de structure la plus im­por­tante du patron de façade. Son im­plé­men­ta­tion et son éla­bo­ra­tion cons­ti­tuent donc la tâche fon­da­men­tale des dé­ve­lop­peurs qui sou­hai­tent sim­pli­fier leurs logiciels complexes en utilisant ce patron de con­cep­tion pratique. Une fois im­plé­men­tée, les objets clients concernés con­centrent toute leur com­mu­ni­ca­tion sur la classe façade, qui devient ainsi la seule instance de ce nouveau système dont les clients dépendent di­rec­te­ment.

Le diagramme de classes qui suit, en langage de mo­dé­li­sa­tion UML, explicite l’in­te­rac­tion des clients, de la façade et des classes de sous-systèmes selon le facade pattern.

Image: Patron de façade : diagramme UML
Le nombre de quatre paquets de classes dans le diagramme UML a ici valeur d’exemple. En théorie, vous pouvez utiliser la classe Façade pour contrôler un nombre illimité de classes dans le sous-système.

Avantages et in­con­vé­nients du facade pattern

Les avantages du patron de façade sont évidents : la façade « cache » les sous-systèmes sous-jacents d’un logiciel et réduit ainsi leur com­plexité. En outre, cette solution favorise le principe du couplage faible. Grâce au faible degré de dé­pen­dance des dif­fé­rents com­po­sants les uns des autres, les chan­ge­ments (mo­di­fi­ca­tions, main­te­nance) sont possibles à tout moment et ne causent pas de dé­sa­gré­ments majeurs, car ils n’ont la plupart du temps qu’un effet local. Ce couplage faible permet également de faciliter l’extension d’un sous-système.

Note

Si les clients dépendent d’un accès direct à certaines classes du sous-système, celui-ci peut également être accordé dans le patron de façade : dans ce cas, seule la vi­si­bi­lité du sous-système doit être pro­gram­mée afin qu’un client puisse con­tour­ner la façade si né­ces­saire.

Avantages In­con­vé­nients
Réduit la com­plexité des sous-systèmes Im­plé­men­ta­tion complexe (surtout avec un code déjà existant)
Favorise le principe du couplage faible La solution est couplée à une étape indirecte sup­plé­men­taire
Les logiciels sont plus flexibles et plus faciles à étendre Degré élevé de dé­pen­dance de l’interface de la façade

Scénarios d’ap­pli­ca­tion du facade pattern

Les pro­prié­tés du patron de façade sont in­té­res­santes dans plusieurs scénarios d’uti­li­sa­tion. Le but premier est de disposer d’une interface uniforme pour accéder à des sous-systèmes complexes ou à un nombre infini d’objets. Une façade promet ici une grande sim­pli­fi­ca­tion ; c’est pourquoi l’uti­li­sa­tion de la stratégie de patron de façade devrait jouer un rôle pri­mor­dial dans la pla­ni­fi­ca­tion du projet.

Un autre cas d’uti­li­sa­tion typique est celui des logiciels où la dé­pen­dance entre les clients et les sous-systèmes sous-jacents doit être réduite au minimum.

Enfin, l’uti­li­sa­tion du patron de façade est payante lorsque vous planifiez un projet de logiciel qui doit être divisé en plusieurs couches. Les façades en tant qu’in­ter­faces de com­mu­ni­ca­tion entre les couches offrent également plus de flexi­bi­lité pour l’extension et l’adap­ta­tion ul­té­rieures des com­po­sants.

Exemple de code : patron de façade

En tant que patron de con­cep­tion, le facade pattern n’est pas lié à un langage de pro­gram­ma­tion spé­ci­fique. Cette solution est notamment utilisée en C++, C#, Ja­vaS­cript, Java, PHP et Python. L’exemple de patron de façade suivant est basé sur un code Java. Pour cela, nous nous sommes inspirés du tutoriel de patron de façade trouvé sur tu­to­rials­point.

Dans cet exemple, une interface « Shape » ap­pli­cable uni­ver­sel­le­ment doit être définie pour les objets re­pré­sen­tant des formes géo­mé­triques. De plus, nous devrons générer des classes concrètes qui im­plé­men­tent cette interface, ainsi qu’une classe façade appelée « Sha­pe­Ma­ker » qui est chargée de déléguer les demandes des clients.

Nous com­men­çons par créer l’interface Shape.java avec le code suivant :

public interface Shape {
	void draw();
}

La deuxième étape consiste à créer trois classes concrètes avec Rectangle.java (classe pour les objets rec­tan­gu­laires), Square.java (classe pour les objets carrés) et Circle.java (classe pour les objets ronds), qui im­plé­men­tent l’interface :

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()");
	}
}

Enfin, la classe façade Sha­pe­Ma­ker est intégrée dans le code. Les clients peuvent désormais y accéder pour générer les dif­fé­rentes formes :

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();
	}
}
Aller au menu principal