Architecture en couches : façades et factory

[yo_haha]

Bonjour,

J'ai une architecture avec une couche façade dans laquelle on trouve les modules :
* facade : contenant les interfaces (java) des façades. Il est indépendant du module services de la couche métier ;
* facadeImpl : contenant les implémentations des interfaces des façades. Il a une dépendance vers le module services de la couche métier.

Je veux ajouter une factory pour permettre au client d'accéder aux interfaces. Cette factory permettra au client d'instancier les classes de facadeImpl sans qu'il ait accès à ce module. Le client ne connaît que le module facade.

Je voudrais savoir où mettre la factory dans le découpage de mon application.

Est-ce que je le met dans le module facade ou je le met dans un module à part ? Sachant qu'il devra être accessible par le client.

A quoi sert vraiment le fait d'avoir facade et facadeImpl ? Quelle est la valeur ajoutée d'avoir des interfaces et ensuite une implémentation de ces interfaces dans la couche facade ?

Cordialement.

[kain_tn]

Bonjour,

Tu pourrais mettre ta factory dans le module facade; ça n'est pas très important (tu peux regarder la hiérarchie du package java.net par exemple).

L'intérêt des interfaces est multiple; parmi les plus intéressants:

• cela permet d'avoir un couplage faible entre tes classes, très utile par exemple si tu dois écrire des tests unitaires. (tu passe alors par des objets factices ou mock objects)
• cela permet à des équipes différentes de travailler en même temps sur des parties différentes d'un même projet, et de pouvoir connecter ces parties entre elles à la fin (programmation par contrat)
• cela permet de pouvoir changer/tester des implémentations de tes interfaces à la volée, et c'est particulièrement puissant quand tu utilise des patterns tels que l'IoC
• l'héritage multiple n'existant pas pour les classes en Java, cela permet de pouvoir l'émuler: une classe peut implémenter autant d'interfaces qu'elle veut, et donc peut être de différents types (typage, polymorphisme, ...)
• enfin, cela permet de s'assurer (ça rejoint le point 2) que les personnes qui développeront de nouvelles facades respecteront les signatures des méthodes définies dans l'interface (c'est du typage en fait)

[yo_haha]

Je te remercie kain_tn pour ta réponse.
1. Le mieux est mettre des interfaces ou des classes génériques ?
2. Si je mets factory dans facade j'aurai facade qui dépend de facadeImpl et facadeImpl qui dépend de facade. Est-ce normal d'avoir deux modules avec une dépendance dans les deux sens ?

[pseudocode]

Personnellement, je ferais cela ainsi:

Facade.java

Code java :

1
2
package com.myapp.facade;
public interface Facade { /* ... */ }

FacadeImpl.java

Code java :

1
2
package com.myapp.facade;
class FacadeImpl implements Facade { /*... */ } // classe en visibilité "package"

Factory.java

Code java :

1
2
3
4
package com.myapp.facade;
public class Factory {
	public Facade getFacade() { return new FacadeImpl(); }
}

Utilisation en dehors du pacakge:

Code java :

1
2
3
4
import com.myapp.facade.*;
public static void main(String[] args) {
	Facade f = new Factory().getFacade();
}

[yo_haha]

Je te remercie Xavier pour ta proposition.

[kain_tn]

Envoyé par yo_haha

1. Le mieux est mettre des interfaces ou des classes génériques ?
?

Personnellement je privilégie les interfaces au reste. Je passe par des classes abstraites (je pense que c'est ce que tu voulais dire, car les classes génériques sont les classes paramétrées) si j'ai besoin de définir du code à hériter.

Envoyé par yo_haha

2. Si je mets factory dans facade j'aurai facade qui dépend de facadeImpl et facadeImpl qui dépend de facade. Est-ce normal d'avoir deux modules avec une dépendance dans les deux sens ?

Non, ce n'est pas terrible en effet, mais pseudocode t'as déjà donné une bonne solution