[Java] Pattern Facade et accès aux packages

Version imprimable

09/03/2006, 15h19
manube

[Java] Pattern Facade et accès aux packages

Salut tout le monde,

Bon je vais essayer d'être concis...
Mon pb vient avec l'utilisation du design pattern Facade. Celui-ci me permet de "masquer" les autres classes de mon package et je voudrais aller un peu plus loin et "interdire" l'accès à ces autres classes afin de ne pas seulement proposer une interface de communication mais d'imposer l'utilisation de cette Facade.

Je vais illustrer mes propos en vous schématisant l'architecture de mon appli :
- Le package mon.package qui contient Facade
- le package mon.package.businesslogic : Les interfaces qui définissent la couche métier de l'appli
- le package mon.package.factory : Les factories qui me permettent de construire les objets métiers de mon appli (du package businesslogic)
- le package mon.package.businesslogic.impl : l'implémentation des interfaces définissant la couche métier
- le package mon.package.dao : La couche d'accès aux données.

Je voudrais interdire l'accès aux packages businesslogic.impl et dao pour toutes les classes ne faisant pas parties du package mon.package. Cela permettra lors de la réalisation de l'interface graphique de garantir que seules les méthodes "autorisées" seront utilisées et qu'aucun développeur ne sera tenté d'appeler directement les méthodes des classes dao au lieu d'utiliser les fonctionnalités de la classe Facade.

Voilà j'espère que qqu'un aura compris mon pb et que mieux encore il aura une solution à proposer!!

Merci d'avance

Manu
09/03/2006, 15h56
bidi

Hmmm je n'ai pas l'impression que ce soit possible (je me trompe peut-être mais...)
Le pattern façade permet de donner une vue simplifiée, de rajouter une couche d'abstraction, mais les fonctionnalités sous-jacentes peuvent quand même être accédées individuellement si on le désire...
Le seul moyen que je vois est de ne pas documenter tes autres classes :-)
09/03/2006, 16h06
Deadpool

Ou alors,mais pas très propre, tu met toutes tes classes dans mon.package et tu vire le public devant la déclaration de tes classe sauf bien sur pour la classe Facade. Le modificateur par défaut correpondant à une vue package-view, les classes extérieures aux package mon.package n'auront pas accès à tes autres classes. Facade y aura bien accès puisqu'il fait partie du package. Et les classes extérieures auront bien accès à Facade puisqu'elle est déclarée en public.

Il faut aussi plomber le package pour éviter que des petits malins tentent d' accéder à tes classes planquées en déclarant que leur classe fait partie de mon.package.
09/03/2006, 16h11
manube

Merci,
J'espérais une réponse un peu plus enthousiaste mais j’ai déjà pas mal galérer avant de poster ce message alors je n’étais pas trop optimiste (j’ai déjà essayé en trafiquotant les modificateurs d’accès sans succès :pleure: ).
Ta solution de ne pas documenter c’est un peu barbare qd même!
J’ai tjs la solution de mettre toutes les classes dans le même package et de ne rendre publiques que celles qui doivent être vues de l’extérieur mais je ne trouve pas ça très joli ni très pratique qd on a un bon paquet de classes…

:arf:
09/03/2006, 16h13
Deadpool

Le problème de java c'est qu'il ne gère pas de hierarchie de package comme il peut le faire pour les classes.

Ca c'est dommage. :?
09/03/2006, 16h18
FreshVic

Certains te dirais que tu ne peux pas empecher un mauvais developpeur de faire n'importe quoi , du moment que tu documente bien et que tu precise bien de passer par la facade , tu as ta conscience pour toi !!
09/03/2006, 16h23
bidi

Sinon j'ai un truc crade :-p :-D
Tu passes par réflexion dans ta façade et tu mets tes constructeurs en private :-)

Par exemple tu déclare une classe Loader comme suit:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public class Loader { /** * Constructeur privé */ private Loader(){ // } public void someMethod() { // } }
puis dans ta façade tu fais:
Code:

1 2 Loader load = (Loader) Loader.class.newInstance();
puis tu peux appeller les méthodes de Loader puisqu'elles sont publiques ;-)

Citation:
Envoyé par bidi
Par exemple tu déclare une classe Loader comme suit:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public class Loader { /** * Constructeur privé */ private Loader(){ // } public void someMethod() { // } }
puis dans ta façade tu fais:
Code:

1 2 Loader load = (Loader) Loader.class.newInstance();
puis tu peux appeller les méthodes de Loader puisqu'elles sont publiques ;-)
Et voila patatra tu viens de donner la solution aux utilisateur du package pour ne pas passer par la facade .
Effectivement cette solution est pas propre mais elle fonctionnerais , sauf qu'en lisant le code de la facade , l'utilisateur pourrat tres facilement en faire autant !! :)

09/03/2006, 16h41
bidi

Ben ui, y'a pas de solution miracle ;-p ce n'est qu'un 'workaround' mais ça peu peut-être le dépanner ;-)
09/03/2006, 16h45
manube

Merci pour ces idées originales!
Bon je crois que finalement je vais garder ma conscience pour moi comme on me l'a proposé et que je vais éviter les trucs crades (même si j'apprécie l'idée!).
Et je vais fouetter les développeurs qui n'utilisent pas la facade :sm:
09/03/2006, 16h46
afrikha

Petite précision: le design pattern façade permet d'avoir une interface pour dialoguer avec un système sous-jacent complexe mais rien n'interdit de faire appel directement au sous-système.
Voilà ça ne résout pas ton problème je sais, mais c'est juste pour éclairer un peu l'intention du design pattern façade.
09/03/2006, 16h51
manube

C'est bien ce que j'avais compris pour le pattern facade mais j'espérais pouvoir forcer son utilisation...
09/03/2006, 17h12
dlemoing

Dans le fonctionnement interne de ta facade, tu peux initialiser une variable ThreadLocal qui sera utilisé par les autres éléments de ton package.
Si le ThreadLocal n'est pas initialisé, tu peux en déduire que tu n'es pas passé par la facade et partir en erreur technique (unchecked pour ne pas pourrir la signature des méthodes).
Je vois bien cette solution implémentée avec une classe interne qui se chargera de l'accès au ThreadLocal (pas le temps d'ecrire le code, ptet tout a l'heure), pas très difficile et mutualisable sous forme d'un aspect avec l'aide d'un proxy dynamique (cela suppose l'utilisation de bonnes pratiques objet et de l'utilisation d'interfaces).
09/03/2006, 17h25
manube

Je vais me pencher sur l'

Citation:

aspect avec l'aide d'un proxy dynamique

car j'ai un peu du mal à tout bien situer mais je pense avoir à peu près compris ce que tu proposes.
Si tu veux donner un morceau de code pour être sur que le message soit bien compris je n'ai rien contre :lol: !!!
Merci en tout cas

Première étape, définir des interfaces :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public interface Facade &#123;
    public void doTiti&#40;&#41;;
    public void doToto&#40;&#41;;
    public void doTata&#40;&#41;;
    public SecuriteFacade getSecuriteFacade&#40;&#41;;
&#125;

public interface SecuriteFacade &#123;
    public boolean isPasseParFacade&#40;&#41; throws SecuriteFacadeException;
&#125;

public interface Dao1 &#123;
    public void doLoad1&#40;&#41;;
    ...
&#125;

public interface Dao2 &#123;
    public void doLoad2&#40;&#41;;
    ...
&#125;

Voila le code de la facade :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public class FacadeImpl implements Facade &#123;
    private class SecuriteFacadeImpl implements SecuriteFacade &#123;
        private static ThreadLocal passageDansFacade = new ThreadLocal&#40;&#41;;

        public SecuriteFacadeImpl&#40;&#41; &#123;
            passageDansFacade.set&#40;Boolean.FALSE&#41;;
        &#125;
        public boolean isPasseParFacade&#40;&#41; throws SecuriteFacadeException &#123;
            return &#40;&#40;Boolean&#41;passageDansFacade.get&#40;&#41;&#41;.booleanValue&#40;&#41;;
        &#125;

        public void setPassageParFacade&#40;boolean valeur&#41; &#123;
            passageDansFacade.set&#40;new Boolean&#40;valeur&#41;&#41;;
        &#125;
    &#125;

    public SecuriteFacadeImpl secu = new SecuriteFacadeImpl&#40;&#41;;

    public SecuriteFacade getSecuriteFacade&#40;&#41; &#123;
        return secu;
    &#125;

    public void doToto&#40;&#41; &#123;
        secu.setPassageParFacade&#40;true&#41;;
        ...
        secu.setPassageParFacade&#40;false&#41;;
    &#125;
    ...
&#125;

Une classe helper :

Code:

1
2
3
4
5
6
7
8
9
public class SecuriteFacadeUtils &#123;
    ...
    public SecuriteFacadeUtils&#40;SecuriteFacade secu&#41; &#123;
        this.secuFacade = secu;
    &#125;
    public boolean estPasseParFacade&#40;&#41; &#123;
        return secuFacade.isPasseParFacade&#40;&#41;;
    &#125;
&#125;

Le code valable pour les DAO :

Code:

1
2
3
4
5
6
7
8
public class Dao1Impl implements Dao1 &#123;
    ...
    public void doLoad1&#40;&#41; &#123;
        secuFacadeUtil.estPasseParFacade&#40;&#41;;
        ...
    &#125;
    ...
&#125;

Concernant ce que je disais par rapport à l'aspect avec un proxy dynamique, j'ai dit une betise. Pour bien faire, il faudrait utiliser AspectJ car l'utilisation d'un proxy dynamique ne garantit en rien que le développeur n'utilisera pas l'objet wrappé directement.

Pour info : http://java.sun.com/j2se/1.3/docs/guide/reflection/proxy.html

10/03/2006, 10h06
manube

Merci pour ces conseils éclairés!
C'était bien ce que je pensais avoir compris mais par contre il me reste une petite question:
Pourquoi utilises tu un ThreadLocal et pas simplement un boolean?

Par contre je connaissais la programmation par Aspect que de nom et c'est vrai que ca a l'air plus qu'intéressant. Ca pourrait permettre de déléguer toute cette gestion à un aspect... donc peut-être même (je m'avance) de simplifier encore plus ton code... mais bon je m'avance...

Citation:

Envoyé par manube

Merci pour ces conseils éclairés!
C'était bien ce que je pensais avoir compris mais par contre il me reste une petite question:
Pourquoi utilises tu un ThreadLocal et pas simplement un boolean?

Parceque je considerais que tu utilisais une seule instance de FacadeImpl et qu'elle devait donc être thread-safe.

Citation:

Envoyé par manube

Par contre je connaissais la programmation par Aspect que de nom et c'est vrai que ca a l'air plus qu'intéressant. Ca pourrait permettre de déléguer toute cette gestion à un aspect... donc peut-être même (je m'avance) de simplifier encore plus ton code... mais bon je m'avance...

On peut simplifier mon code, mais pour cela il faut utiliser AspectJ ou un outil intervenant au niveau du byte-code. L'utilisation d'un framework plus léger basé sur des proxy dynamiques ne suffit pas à garantir la non utilisation de ta classe en dehors de la démarcation matérialisée par la facade.

Une autre solution, un objet qui lance une exception et vérifie la stack trace :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 public class Dao1Impl implements Dao1 { public LaClasseSecu secu; public void doLoad1() { secu.assertEstPasseParFacade(); ... } } public class LaClasseSecu { public void assertEstPasseParFacade() throws RuntimeSecuFacadeException{ try { throw ExceptionBidon(); } catch (ExceptionBidon e) { StackTraceElement[] st = e.getStackTrace(); boolean passeParFacade = doRechercheClass(FacadeImpl.class); if (!passeParFacade) throw RuntimeSecuFacadeException(); } } ... }
Avantage : pas de code dans la facade et également modélisable dans un aspect

10/03/2006, 10h41
Satch

On est obligé de lancer une exception pour vérifier la stackTrace ?
Parce que bon, c'est couteux.
10/03/2006, 11h12
adiGuba
Salut,

Citation:

Envoyé par Satch

On est obligé de lancer une exception pour vérifier la stackTrace ?

Non on n'est pas obligé de la lancer. On peut se contenter de la créer :

Code:

StackTraceElement[] st = new Exception().getStackTrace();

Et avec Java 5.0 on peut même passer par la classe Thread :

Code:

StackTraceElement[] st = Thread.currentThread().getStackTrace();

Citation:

Envoyé par Satch

Parce que bon, c'est couteux.

Ce qui est coûteux ce n'est pas de lancer l'exception, mais bien la génération du stack (cf ce message sur mon blog : Exception & Performance), donc dans tout les cas ce sera assez coûteux...

Il faudrait donc limiter cela au developpement et le désactiver en release, soit via des aspects comme l'indique dlemoing, voir de la "compilation pseudo-conditionnelle" :
Code:

1 2 3 if (DEBUG==true) { assertEstPasseParFacade(); }
Voir même via les assert (code Java 1.4 minimum) :

Code:

assert assertEstPasseParFacade();

a++