Discussion :

[Serrato]

Bonjour,

Je ne sais pas si la méthode dont je vais parler est vraiment un design pattern, mais concernant la programmation orientée objet, elle est surement bien ici.

J'utilise parfois une méthode, mais sans jamais avoir lu d'articles sur elles. J'espère donc que vous la connaissez, pour que je puisse trouver des infos dessus.

Voici la bête:
Le but est qu'un objet ait un accès restreint aux méthodes d'un autre objet, puisqu'il n'a pas les droits complets dessus (un peu comme un programme qui n'est pas root, qui n'a donc que des droits utilisateurs sur le système).

Pour implémenter cela, j'utilise ce que j'appelle l' "interface restreinte".

Par exemple, il y a un objet de classe System (qu'on nommera ObjSystem) et un objet de classe Program (qu'on nommera ObjProgram). ObjProgram a besoin d'un pointeur vers ObjSystem pour lui faire exécuter des méthodes.
Cependant, ObjProgram n'a pas le droit d'appeler toutes les méthodes de ObjSystem, car cela pourrait tout casser. Il faut donc qu'il ait accès à seulement quelques méthode de ObjSystem, comme GetTime (c'est l'accès restreint).
Pour cela, on crée une nouvelle classe, SystemForUser, dont dérive System, qui ne propose que GetTime et les autres méthodes qui ne risquent pas de tout casser si elles sont appelées par n'importe qui. Cette classe n'aurait pas été crée si ce n'était pour proposer ces méthodes.
On donne alors un pointeur vers ObjSystem à ObjProgram, mais de type SystemForUser. ObjProgram ne peut donc avoir accès aux méthodes à risque de System. On a bien créer un accès limité.

Est ce que vous connaissez le nom de cette méthode?
Est ce que vous avez des infos là dessus?

Merci d'avance!!!

Remarque: en C++, on doit pouvoir faire l'équivalent en mettant les classes à risque de System en protected, friend des classes autorisées à les appeler, ou en utilisant des const.

[Serrato]

Encore une chose: si vous connaissez d'autres méthodes pour faire la même chose (limiter l'accès à certaines méthodes pour certains objets), je suis interessé!

[laurent_m]

Allez vite fait
tu peux consulter :
Cet article du MSDN
Les articles cités dans cette simple recherche google
Ou ceci du NIST

[PanicKernel]

Pour les contrôles d'accès j'utilise le design pattern proxy.

[laurent_m]

Ah oui c'est excellent comme pattern dans ce genre de situation.. je n'y avais pas pensé

Y en a tellement

[Serrato]

HOURRA ! ! !
j'ai trouvé! C'est le design pattern Façade.

Merci quand même de vos réponses, ça m'a aidé!

Proxy n'est pas exactement ce que je veux. J'ai l'impression que c'est "On fournit une interface et on permet d'appeler toutes ses méthodes, mais la façon dont ça tourne derrière est cachée".

Ce que je veux, c'est "un objet A possède un objet B. A doit preter B à un objet C, mais il ne veux pas que C puisse appeler certaines méthodes de B". Façade dit de faire une classe PublicB, qui ne contient que les méthodes authorisées pour C et de donner l'objet B sous le type PublicB. Ainsi, C ne peut pas appeler les méthodes interdites de B puisqu'il n'a que l'interface PublicB, et non l'interface B.

[PanicKernel]

Oui avec proxy tout est disponible mais c'est à l'exécution que le flot est controlé, c'est dynamique.

Toi tu souhaites un controle statique, mais le but de la façade n'est pas de filtrer des méthodes, ça sert à masquer la complexité d'un système en proposant des méthodes de haut niveau, je l'utilise surtout pour des web services.

[Serrato]

Toi tu souhaites un controle statique, mais le but de la façade n'est pas de filtrer des méthodes, ça sert à masquer la complexité d'un système en proposant des méthodes de haut niveau, je l'utilise surtout pour des web services.

Effectivement, j'ai vu des exemples de Façade comme ça (exemple: http://fr.wikipedia.org/wiki/Façade_..._de_conception)), mais j'en ai aussi vu comme je le décris, avec filtrage de méthodes (exemple: http://www.javacamp.org/designPattern/ -> Façade).