Discussion :

[onlytoine]

Hello,

Je voudrais avoir des regards éclairés sur une modélisation dont voici les caractéristiques.

Des "documents" sont stockés sur un serveur. Des méthodes permettent de récupérer un document donné (en faisant abstraction de son mode de stockage) et monte une représentation du contenu du document sous forme d'un arbre d'objets.

Pour des raisons de faciliter d'évolution, on ne souhaite pas donner accès directement au modèle objets. Les opérations sont accessibles via une API "façade" qui masque les vrais objets à travail des représentations propres, souvent simplifiées, ne montrant que les méthodes nécessaires à l'utilisateur.

Avez-vous des critiques concernant cette architecture?

Merci !
Anthony

[ego]

c'est quoi l'objectif de tout ça ?
On ne peut te répondre avec si peu d'information

[onlytoine]

en fait, l'objectif de mon post est de savoir s'il y a de bonnes pratiques concernant l'exposition d'un modèle objet, des patterns particuliers intéressants, etc...

[ego]

Perso, je ne comprend pas cette volonté de sans cesse vouloir "cacher" la structure des objets.
Un "client" a besoin d'obtenir de l'information et quelque soit le modèle objet, il faudra bien qu'il obtienne cette information. Aussi, il faut se pencher sur quelle information est utile au "client", ensuite, ce qui se passe "derrière" n'a pas d'importance.
Ce que je veux donc te dire c'est qu'il faut avant tout savoir ce que l'on doit fournir comme information, c'est vraiment cela qui est le point central = savoir quel est le "contrat". Il ne s'agit pas de cacher quoi que ce soit ni même de faire "évolutif" car cacher ne veut en fait pas dire grand chose car il y aura de toute manière une dépendance vis-à-vis d'une API et qui dit API dit données en entrée/sortie donc modèle objet.

[souviron34]

tout à fait..

je dirais même qu'au contraire, pour moi (mais je suis biaisé, cela a été mon métier pendant un temps ) c'est la définition même de l'interface qui définit les objets ...

Et si l'info nécessite d'autres "méthodes", eh bien elle doit se débrouiller, en interne...

Si par "cacher" tu entends "séparer", là nous sommes d'accord, mais cela n'a rien à voir.. Les termes veullent dire quelque chose...

[onlytoine]

Merci pour vos messages !

Je veux bien dire "cacher".

Vos remarques m'ont éclairé sur le fond de ma question qui est en fait : faut il mieux masquer complètement la structure objet aux clients en leur proposant une façade masquant le modèle objet interne ou est-il préférable d'exposer directement le modèle objet afin qu'elle puisse le manipuler librement ?

Mon problème est que si on expose le modèle objet, toute modification de celui-ci entraine potentiellement des modifications des clients alors que si on passe par une façade, on peut éviter ce genre de problèmes. Par contre, ne pas donner accès au modèl objet rend son utilisation/manipulation difficile par les clients...

Quelle stratégie avez-vous adoptée dans vos expériences ?

Merci d'avance pour vos réponses !

Anthony

[Mat.M]

Pour des raisons de faciliter d'évolution, on ne souhaite pas donner accès directement au modèle objets. Les opérations sont accessibles via une API "façade" qui masque les vrais objets à travail des représentations propres, souvent simplifiées, ne montrant que les méthodes nécessaires à l'utilisateur.

Avez-vous des critiques concernant cette architecture?

No comprendo ! En POO ce sont les caractéristiques de l'encapsulation par exemple un objet qui expose attributs et méthodes soient publiques soient privées.
Si tu veux accéder à des attributs privés d'un objet, on utilise des "getters/setters"

Mon problème est que si on expose le modèle objet, toute modification de celui-ci entraine potentiellement des modifications des clients alors que si on passe par une façade, on peut éviter ce genre de problèmes. Par contre, ne pas donner accès au modèl objet rend son utilisation/manipulation difficile par les clients...

Quelle stratégie avez-vous adoptée dans vos expériences ?

C'est une analyse relevant de la Programmation Orientée Objet.
C'est à toi de décider ce qui doit être exposé ou non,ce qui est fonctionnel ou non ... ( désolé de faire des lapalissades mais c'est évident )
donc il faut prendre un éditeur UML par exemple et faire une analyse avec des diagrammes UML..
Après pour que les objets puissent évoluer tu peux prendre les méchanismes de l'héritage..d'un objet de base on conserve ses attributs de base et on le fait évoluer.

Pour faire plus pratique un bon bouquin de C++ ou Java et des exercices pour mettre tout cela en oeuvre..

Une autre piste ce sont des bouquins sur les Design Patterns
http://en.wikipedia.org/wiki/Design_Patterns

[ego]

Le patterns donnent effectivement de bonnes idées.
Avec l'âge, je penche malgré tout vers une approche très "données-traitements" entre, disons, client et serveur. Ce n'est pas que je renonce à l'objet, pas du tout mais disons que bien souvent, et du point de vue strictement fonctionnel, on a des traitements qui manipulent des données. La dimension "objet" (le truc qui a des données et des traitements) n'est pas très "intéressante" du point de vue utilisation de la partie dite "données" quand on se positionne au niveau du système informatique.
Bref, faire joujou avec les objets "à l'intérieur", ok, mais pour ce qui est au niveau de la.....façade, pas super intéressant.

Bref, des façades pour encapsuler ce qui se passe à l'intérieur. Notes que je n'aime pas quand même ce mot encapsuler car il laisse supposer que ce qui est "supérieur" c'est ce qui se passe à l'intérieur (rien à voir avec un truc Bio ). Or, comme je l'ai dit, ce qui a de l'importance c'est l'interface que l'on veut/doit offrir. La façade c'est donc bien ce qui prime = l'interface disent d'autres.

[onlytoine]

Merci Mat.M mais je connais bien la POO je pense

ego : je vois bien ce que tu veux dire concernant ton approche donnée-traitement. Mais quand tu parles de façade, c'est directement des interfaces sur la structure objet du modèle métier ? Ou alors des façades qui donnent une abstraction de la structure objet ?

Vu ce que tu as dit au début, il semble que tu sois plutot contre le fait de masquer la structure objet... Je voudrais avoir un peu plus de détails sur ton point de vue à ce sujet !

Merci !

Anthony

[ego]

Ben en fait, il y a 2 patterns bien connus pour résumer ce qui me parait être une bonne solution : Façade couplée au Data Transfert Object. Les différents DTO correspondent ce que le "client" attend. Mon "contrat" est donc le "couple" Façade + les DTO nécessaire aux paramètres des opérations de ma façade (oui plusieurs façades bien entendu). Le contrat est donc ce qui ne bouge pas vis-à-vis du "client".
Malgré ce que je dis, tout dépend du type d'application. Ce que je décrit est valable surtout dans le cas d'applications offrant des services à d'autres applications ou dans le cas de la partie "serveur" d'une application client/serveur avec nécessité d'avoir un client sur une autre machine que le serveur. Dans le cas d'application moins contraigante genre application Web avec tout sur une même machine, on peut faire plus simple.

[souviron34]

Dans le cas d'application moins contraigante genre application Web avec tout sur une même machine, on peut faire plus simple.

mais il n'empêche que en gros, l'interface (au sens GUI, au sens "boutons+champs+choix+++") crée une série d'"objets" utilisateurs, et que , à mon humble avis, pour faire du développement propre, ré-utilisable, souple, on a effectivement intérêt à suivre cette logique.

Je crois que ce que ego et moi voulons dire c'est que l'architecture "objet" sous-jacente ne DEVRAIT pas avoir d'influence sur l'interface/le GUI. Soit elle est directement copiée de l'interface/du GUI, soit elle en est différente. Mais dans tous les cas ce n'est pas le modèle de données qui s'impose à l'utilisateur, mais l'utilisateur qui impose un modèle de données "interface", à partir duquel on déduit un modèle "applicatif", profond ou immédiat.

J'ai bien precisé "GUI ou interface", car c'est valable que le client soit un vrai utilisateur (GUI) ou une autre appli (interface) : il y a des contraintes de groupement, d'actions, d'ordre, etc... qui doivent être respectées, quel que soit ce que l'on fait "en dessous".

[JPhi33]

Bonjour à tous,

Je travaille en architecture orientée service (SOA en anglais) et la question de la "façade" est au coeur de ce genre d'architectures.

Le choix qui a été fait par la société dans laquelle je travaille est de n'exposer que les services dits fonctionnels, c'est-à-dire ceux qui ont un sens pour l'utilisateur (le client) des services, que celui-ci soit une personne, une application ou un autre service fonctionnel. Evidemment, pour rendre son service, le service fonctionnel a besoin de services plus techniques, mais ceux-ci sont masqués. Les services techniques ont des fonctions dédiées : agrégation logique des données, accès physique aux données, couche de communication (eventuellement entre environnements techniques hétérogènes), règles métier, etc.

Il ne s'agit pas de "masquer" artificiellement le modèle des services mais de ne rendre accessible que ce qui est pertinent pour l'utilisateur.

Si on veut appliquer ces principes au modèle objet d'onlytoine (question initiale), il ne faudrait pas maquer le modèle objet mais ne donner accès qu'aux objets pertinents pour l'utilisateur du modèle. L'accès peut être "habillé" (GUI) mais ça ne doit pas remettre en cause le principe.


JPhi33

[souviron34]

je suis assez d'accord avec toi, cependant je pense que ce qui nous a paru un peu excessif, c'est la manière de présenter...

Contrairement à ce que tu dis :

..
Il ne s'agit pas de "masquer" artificiellement le modèle des services mais de ne rendre accessible que ce qui est pertinent pour l'utilisateur.

Si on veut appliquer ces principes au modèle objet d'onlytoine (question initiale), il ne faudrait pas maquer le modèle objet mais ne donner accès qu'aux objets pertinents pour l'utilisateur du modèle. L'accès peut être "habillé" (GUI) mais ça ne doit pas remettre en cause le principe.

le PO suggérait avec sa tournure de phrase :

faut il mieux masquer complètement la structure objet aux clients en leur proposant une façade masquant le modèle objet interne ou est-il préférable d'exposer directement le modèle objet afin qu'elle puisse le manipuler librement ?

*

que :

• la notion d'objet applicatif était directement liée à la partie accessible au client par un lien univoque
• et que par conséquent le choix se résumait à soit faire accepter par l'utilisateur le modèle choisi, soit les déconnecter totalement.

Il est bien évident, que ce soit d'après tes remarques que d'après celle d'ego ou les miennes, que nous optons tous pour une zone un peu plus grise...

D'une part comme dit plus haut, il y a plusieurs couches et des objets particuliers aux couches "inférieures" ou techniques, et d'autre part que même dans la couche "supérieure" ou applicative, il n'y a pas de recouvrement total entre la définition d'un "objet" GUI du point de vue de l'utilisateur et du point de vue du logiciel (ne serait-ce que les méthodes de tracé et les attributs techniques de la station, de l'écran, du contexte, les curseurs etc..., qui ne font pas partie d'un quelconque modèle d'objet "utilisateur", sauf pour des applis bien spécifiques).

[Hephaistos007]

Je ne pensais pas que le simple pattern "Facade" (http://fr.wikipedia.org/wiki/Fa%C3%A..._de_conception) pouvait engendrer autant de réponses philosophiques...

[ego]

on est donc tous d'accord....
L'informatique ou plutôt la conception d'applications informatique est bien entendu affaire de philosophie, tu as raison.
L'approche dite SOA n'a rien de très nouveau, c'est juste une nouvelle manière d'habiller des principes très anciens (à l'échelle de l'informatique bien sûr) et c'est ce que pronait Microsoft avec son architecture COM avec des composants uniquement stateless au contraire de la tentative, pas très heureurse, des EJB entité côté Java. Mais tout ceci (côté Java), c'est bien arrangé.

[onlytoine]

Hmm hmm

Merci pour vos réponses très intéressantes.

Pour vous donnez un exemple plus concret de ce qui m'a amené à me poser cette question :

- il existe un modèle objet d'un domaine particulier (il existe sous forme d'un ensemble d'objets struturés sous forme d'un arbre). Dans mon cas, c'est un document, comment des blocs de texte, tableaux, graphiques, ...

- dans mes expériences précédentes, la partie interface graphique avait accès à l'ensemble de la hiérarchie des objets d'un document. Pour une opération de copier/coller, elle pouvait donc par exemple cloner une partie de l'arbre et la placer à l'endroit voulu dans l'arbre du document. L'interface graphique pouvait aussi facilement ajouter des listeners sur les objets de l'arbre afin d'être prévenu des modifications apportées...

- dans une autre expérience aujourd'hui, l'architecture me surprend. Le modèle objet est complètement isolé : l'interface graphique (le monde extérieure plus généralement) n'y a pas accès. En regardant de plus près, une autre couche a été écrite au dessus du modèle objet. Pour chaque objet du domaine, il existe donc une surcouche... Et c'est cette surcouche qui gère la cohérence du modèle...

J'espère que je suis assez clair dans mes explications

J'essaie donc de savoir si la dernière architecture est mal goupillée ou pas...

Merci pour vos réflexions à venir !

Anthony

[ego]

J'ai l'impression que tu es en fait devant 2 types d'applications.
La première est plutôt de type "standalone" et son architecture est donc cohérente (histoire des listeners par exemple, qui marche difficilement en mode client/serveur). La seconde est probablement plus de type client/serveur et son architecture est donc elle aussi cohérente car il y a une séparation physique des "tier" donc transport de données.
Les 2 architectures sont valables dans leur domaine même si beaucoup de travaux et d'articles du moment discutent de la seconde (enfin j'ai l'impression).

[onlytoine]

Ce n'est pas faux, la deuxième est effectivement client-serveur.

Le principe est le suivant : un client (qui peut être de diférente nature, c'est à dire UI ou pas) demande au serveur l'ouverture d'un document. Celui-ci charge le document et monte une structure objet en mémoire (c'est important : il ne s'agit pas de chargeant à la demande comme on peut le voir avec des systèmes d'ORM comme Hibernate). Le modèle objet (l'arbre représentant le document) sera libéré lorsque le document sera le client le demandera ou à la fin d'un timeout. Afin de consulter et manipuler le document, les clients utilisent une couche faisant abstraction du modèle objet. Enfin, pas tant que ça car comme je l'ai dit, pour chaque objet du modèle, il existe un équivalent dans la couche "façade". Cette couche est donc très proche du modèle objet.

Je me demande alors qu'elle est l'intérêt d'une telle surcouche... Ne pourrait-on pas plus simplement directement exposé le modèle objet sous-jacent. La façade est bien entendu toujours utile pour offrir des fonctionnalités de haut niveau.

Par ailleurs, je suis tombé sur un article sur wikipedia sur un antipattern nommé "plat de lasagne" parlant d'un problème qui me semble similaire... ça vous dit quelque chose ?

Anthony

[ego]

La question est surtout, dois-tu/peux-tu passer tout ton arbre ou non vers le client ?
Si tu fais cela, plusieurs problèmes vont se poser :

• Problème de bande passante en fonction de la taille de l'arbre
• Problème "d'intelligence" de tes objets. En effet, si tu donnes de l'intelligence aux objets de l'arbre, intelligence "mal placée", tu vas devoir installer des librairies serveur sur le client. Tu risques même d'être dans une impasse. Imagines que tes objets fassent des accès à la base (directement ou pas), que va t-il se passer côté client ? Il se peut qu'il n'y ai pas de problème si tu as chargé, sur le client, ce que l'on appelle la "fermeture transitive complète" mais si ce n'est pas le cas,...

Si tu as un modèle du domaine sans opérations et qu'il n'est pas trop gros, tu peux tout passer sur le client mais sinon, il est peut être préférable de passer par des Data Transfert Objects. Regardes un peu ce qui se dit sur SDO par exemple.