Discussion :

[thebloodyman]

Bonjour,

Je suis actuellement en train de réaliser un projet personnel en JAVA et je bute sur un problème de conception concernant la visibilité des objets de type conteneur. Enfin je pourais avancer sans régler ce souci mais j'aurai l'impression de bacler la conception et j'aime pas trop cette idée...

Dans un programme élaboré en POO, je pense que chaque objet doit avoir une visibilité qui se limite à ses besoins et à ses droits.
Par exemple, je ne veux pas qu’un objet de type UTILISATEUR ait accès directement à un objet de type conteneur d'utilisateurs.
Mais c'est la que j'ai un problème.
Concrètement, si je veux qu'un utilisateur est la capacité à tout moment d'afficher la liste de tous les utilisateurs par le biais d'une méthode il faut que la méthode de l'objet utilisateur ait accès au conteneur.
Or si il a accès au conteneur, un objet utilisateur pourra utiliser des méthodes appartenant à la classe CONTENEUR donc capables de faire tout et n'importe quoi sur le conteneur dont des choses dont un utilisateur langda n'a pas le droit à l'origine, comme par exemple supprimer une voire toutes les occurrences du conteneur.
Donner ce type d'accès a un utilisateur facilite la conception.
Par contre, j'ai l'impression que ça favorisera la difficulté de la gestion des erreurs et des exceptions ainsi que la réutilisation des classes.

Une des solutions que j'envisage pour améliorer la conception est de créer des classes de type "service" dont chacune de ces classes auront un accès au conteneur et présenteront un ensemble de méthode susceptibles d'utiliser ce conteneur.
De cette façon, il me suffira d'ajouter un objet d'une de ces classes de type "service" à une classe type utilisateur afin de donner à l'utilisateur le droit d'accéder au conteneur mais uniquement par le biais de méthode définies dans la classe de type "service".
Je ne sais pas trop si ce type de conception est "bonne".
Si quelqu'un comprend mon problème et a une idée sur la solution à envisager, je suis tout ouie.

Cordialement,

[fremsoi]

Pose plus ta question dans le forum lier au conception etc. tu auras plus de chances d'avoir des personnes qui prennent le temps de répondre à ta question

[thebloodyman]

Merci du conseil
C'est ce que j'ai fait au départ mais j'ai l'impression qu'il n'est pas tres actif...

[wdionysos]

bon c'est pas evident de saisir ou tu veux en venir

quelques exemples valent souvent mieux que de long discours (bon d'accord je suis gonfle de dire ca au vu de la longueur de mes posts mais ce sont de long exemple )

Que developpe tu comme genre d'application ?

si c'est une application web, je te conseille de gerer l'authentification de tes utilisateurs au travers de la session en leur attribuant un grade (admin, manager, redacteur, user par ex), cette info suivant l'utilisateur dans ta session tu peux facilement contitionner un affichage en fonction des droit de l'utilisateur.

Wdionysos

[viena]

Je pense que le coup des services est effectivement un bon plan. Ca rejoint notamment le modèle de séparation des couches en J2EE... s'il est si utilisé, c'est qu'il ne doit pas être mal
Sinon, tu peux mettre certains méthodes en protected et ne faire hériter ton conteneur que par les classes qui ont le droit d'utiliser les méthodes protected... mais bon, ce modele est très spécifique, et ne peut (doit) pas être utilisé dans certains cas... donc tout dépend de ce que tu dois faire.

[xavlours]

Bonjour,
je ne suis pas sur que la visibilité des objets soit un problème de sécurité dans le sens de l'accès à l'information. Si la classe utilisateur n'appelle pas les méthodes "sensibles", pour le debuggage tu n'auras pas de problème. Si un utilisateur a accès à ces méthodes, c'est que le code a été modifié, et dans ce cas tu as un problème plus grave que la gestion des erreurs ou la réutilisation du code. Mais je n'ai peut etre pas bien saisi ton contexte.

J'avais quand meme une idée semblable à celle de viena, qui consiste à construire des packages reflétant les droits d'accès. Tu mets certaines méthodes en visibilité package, ce qui t'évite d'avoir à mettre en place un héritage supplémentaire.
Et +1 pour l'idée de service, je connaissais pas et ca a l'air sympa.

[thebloodyman]

tout t'abord, merci à tous ceux qui ont essayé de m'aider à voir plus clair

wdionysos,

Ou je veux en venir ??
C'est encore un projet mais je souhaite créer un petit jeu en ligne en JAVA genre scrabble et aimerais avoir un code réutilisable(pour changer ), d'ou la recherche d'une conception plus ou moins rigoureuse.

Je pense que le coup des services est effectivement un bon plan. Ca rejoint notamment le modèle de séparation des couches en J2EE... s'il est si utilisé, c'est qu'il ne doit pas être mal
Sinon, tu peux mettre certains méthodes en protected et ne faire hériter ton conteneur que par les classes qui ont le droit d'utiliser les méthodes protected... mais bon, ce modele est très spécifique, et ne peut (doit) pas être utilisé dans certains cas... donc tout dépend de ce que tu dois faire.

J'ai pensé à un moment de me servir des attributs de visibilité "protected" mais n'en faisant cela j'ai l'impression que si la classe Y hérite de la classe X conteneur d'objet, la classe X possédera a son tour aussi une collection d'objets alors que la collection d'objets (ex : users) devrait etre unique.
Enfin peut etre que j'ai mal compris la notion de protected (au passage que je n'ai jamais utilisé) donc désolé d'avance.

xavlours Posté le: Mer Jan 04, 2006 9:34 Sujet du message:

--------------------------------------------------------------------------------

Bonjour,
je ne suis pas sur que la visibilité des objets soit un problème de sécurité dans le sens de l'accès à l'information. Si la classe utilisateur n'appelle pas les méthodes "sensibles", pour le debuggage tu n'auras pas de problème. Si un utilisateur a accès à ces méthodes, c'est que le code a été modifié, et dans ce cas tu as un problème plus grave que la gestion des erreurs ou la réutilisation du code. Mais je n'ai peut etre pas bien saisi ton contexte.

J'avais quand meme une idée semblable à celle de viena, qui consiste à construire des packages reflétant les droits d'accès. Tu mets certaines méthodes en visibilité package, ce qui t'évite d'avoir à mettre en place un héritage supplémentaire.
Et +1 pour l'idée de service, je connaissais pas et ca a l'air sympa.

Pour te répondre concernant la sécurité, je suis d'accord avec toi dans un certains sens.
Certes, si on fait attention à quel objet utilise quelle méthode on assure une cohérence mais hélas nous ne sonmes pas à l'arbis des erreurs de codage.
Un des prémisses de la conception orientée objet est d'assurer que les objets A..Y ne puissent agir sur l'objet Z que par le biais de méthodes qui les limitent par rapport à leurs droits.
Si maintenant tous les objets A..Y ont accès librement à l'objet Z, lors d'un plantage, je pense que retrouver l'erreur deviendra plus compliqué car l'erreur peut venir justement de n'importe ou. Or si tu sais que l'objet Z ne peut etre accèder que par un service Z alors il suffit de regarder les objets qui dont ta conception utilisent le service Z.

Concernant la notion de "services", merci de m'avoir encourrager dans cette voix.
Voulant éviter de réinventer la roue, je me suis renseigné sur quelques design patterns et j'ai l'impression que le design pattern "facade" est pas mal mais je suis pas sur que ca soit la meilleure...
Quelqu'un serait me conseiller ???

[wdionysos]

pour aller plus loin dans la conception selon des design pattern de type facade ou autre, je me declare incompetent. j'ai bien deja realise des classes qui ne communique qu'au travers d'une interface de communication mais je ne sais si cela a a voir exactement avec le model facade...

ne voulant pas dire de conneries et ne maitrisant pas a 100% ce sujet, je prefere le laisser a ceux qui ont une plus grande experience de J2EE et des design pattern ...

WDionysos

[wdionysos]

mais une reflexion suplementaire me vient a l'esprit

en implementant ton code, tu maitrise quand meme ce que tu fais donc si une classe B herite de A c'est pas parce que B a acces aux methodes de A que tu dois les exploiter (gourmand va !!! )

de la meme maniere en implementant ta classe B d'une interface C, celle ci oblige a redefinir les methodes de B pour les utiliser donc tu n'es pas obliger de redefinir celle qui te posseront un probleme

enfin je dis peut etre nimp

WD

[thebloodyman]

wdionysos,

merci pour le gourmand

Concernant ton raisonnement sur les interfaces, je t'avoue que ca me laisse un peu perplexe

de la meme maniere en implementant ta classe B d'une interface C, celle ci oblige a redefinir les methodes de B pour les utiliser donc tu n'es pas obliger de redefinir celle qui te posseront un probleme

Je suis OK avec toi quand tu dis que la classe B devra redefinir les methodes abstraites de B pour les utiliser mais à ma connaissance il va falloir redefinir toutes les méthodes abstraites de l'interface C si je veux que ma classe B soit instanciable.

Peut etre que je n'ai pas compris ou tu voulais en venir...
Mais merci d'essayer

[wdionysos]

oui autant pour moi