Programmation de motifs de conception: Façade ou non?

Question

Un autre gars de notre équipe m'a fourni une bibliothèque comme un pot pour son framework web. Appelons ce cadre «le cadre de mon ami».

Il y a une classe particulière dont j'ai besoin de son cadre. La moitié des propriétés exposées par cette classe est ce dont j'ai vraiment besoin pour ma propre application. L'autre moitié n'est pas nécessaire. Pour récupérer les propriétés de cette classe, vous devez effectuer une manipulation de chaînes. Puisque je vais développer mon propre framework au-dessus de cette classe, je veux découpler autant que possible la dépendance. Peut-être qu'à l'avenir un autre de mes amis développera un meilleur cadre.

Donc ce que j'ai fait, c'est que j'ai généré une classe de façade pour cette classe. Mon propre framework accède aux propriétés à travers ma classe de façade. Si le "Cadre de mon ami" a changé, je dois juste changer une classe de façade et le reste reste le même. En outre, la manipulation de chaîne est effectuée à l'intérieur de la classe de façade. En outre, la classe de façade expose uniquement les propriétés nécessaires. Donc mon propre framework accède simplement aux propriétés en tant que getter/setter normal.

Cependant, j'ai eu une dispute avec ce type. Il me force à utiliser directement sa classe puisque d'abord il ne changera jamais l'implémentation de sa classe. Alors il me dit que l'écriture d'une classe de façade n'a vraiment aucune valeur. Mais je ne suis pas d'accord.

Je me trompe? Je crois que j'ai raison cependant.

Answer 1

Vous n'avez pas tort en principe.

Vous avez tort en ce que ce que vous faites n'est pas une façade. Facade est plus couramment utilisé dans le cas où vous avez une API avec un tas de services. Vous pouvez utiliser tous ces services ensemble, mais cela peut devenir compliqué. Le modèle consiste à mettre en place une interface API unique, la façade, qui coordonne les appels de service en actions logiques utilisables.

Ce que vous faites ressemble plus au modèle d'adaptateur. Vous adaptez sa classe à votre cas d'utilisation en plaçant une autre classe devant lui. Notez, je signale simplement un problème sémantique, en pratique ce que vous faites est une bonne pratique de conception.

Notez également que si vous n'avez pas vraiment l'intention de mettre à jour à l'avenir, vous n'aurez peut-être pas besoin de passer par le problème. Peut-être YAGNI - vous n'en aurez pas besoin.

Answer 2

Cela me semble un bon design.

Les façades fournissent généralement une interface à un plus grand sous-système de classes, mais je ne vois pas pourquoi vous ne pouvez pas utiliser une façade pour accéder à une classe complexe. Il semble que l'autre personne puisse être têtue - donc je pense qu'il est bon de se découpler de son cadre.

Si votre façade est plus facile à utiliser, vous pourriez peut-être l'amener à l'ajouter à son cadre pour le fournir à tous les autres.

Answer 3

Votre approche me semble bonne. Assurez-vous simplement de créer une interface très indépendante de l'implémentation réelle de la structure WHOLE. D'autres ont fait remarquer que c'est un adaptateur, seulement parce que vous essayez de découpler une seule classe, mais je soupçonne que cette classe est couplée avec d'autres. Essayez de répondre à la question: Quels secrets cette façade devrait-elle dissimuler? Essayez de poster certaines des méthodes que vous souhaitez exposer afin que nous puissions discuter.