Bonjour,
Dans mon projet, la partie du système concernant l'application est représentée par une classe.
Pour le moment, on représente chaque mode par une classe différente ... mais qui a la même architecture "physique", seul le comportement change.
Est-il possible et si oui, comment ? de donner un comportement différent à des objets issus d'une même classe ?
Ou il faut absolument avoir des classes différentes ?
Ou alors en utilisant l'héritage ?
Merci de vos réponses.
par définition de ce qu'est une classe les instances d'une même classe partagent un même comportement, c'est a dire que si tu défini une opération 'print' au niveau d'une classe est est vraiment pas souhaitable que pour une instance donnée cela fasse une lecture ;)
Maintenant il y a évidemment des limites à la chose au niveau du détail sinon on ne pourait rien faire, bref si une classe a plusieurs instances ce n'est pas pour qu'elles soient toutes strictement égales ...
Merci pour ta réponse.
Entre-temps, j'ai trouvé une bidouille (c'est sous Tau-G2) avec les diagrammes d'états-transitions.
La dessus je suis totalement d'accord avec bruno_pages; ca fait partie des principes de la POO: une classe = une responsabilite, apres si tu commences a bidouiller comme ca pour arriver a tes fins, c'est que peut etre t'as un probleme de conception quelque part!
Peut-être aller voir le design pattern strategy...
Je ne serai pas aussi catégorique.
Il est possible qu'on décrive au niveau d'une classe, un diagramme d'états-transitions qui fait que les différentes instances de cette classe, les objets donc, ont des comportements tellement dépendant de l'état dans lequel ils sont que l'on a presque l'impression qu'on a à faire à des objets de classes différentes.
Ceci est assez bien illustré d'ailleurs avec le pattern State.
Mais ok, il s'agit quand même de la même classe mais bon......
Bien sur on peut représenter des structures alternatives ds 1 diagramme d'état-transition, mais si cela dépend du type d'objet je suis d'accord avec Nip, il y a peut-etre mieux à faire.
selon le principe ''polymorphisme'' (1 des 9 GRASP), quand des méthodes similaires ont des comportements differents selon les ''types'' d'objets il est conseillé de créer 1 méthode polymorphe.
Bonjour
3 points de vue :
1) Le comportement d'un objet correspond à sa réaction au messages qu'on lui envoie. Ce comportement est le cycle de vie de l'objet ; il se modélise avec une machine à états.
2)Dans le premier post, milk-at parle de "la partie du système concernant l'application".
Je comprend la partie applicative d'une architecture en couche (n-tiers).
Ce qui correspond à un controleur (de Use Case) d'une décomposition Boundary-Control-Entity (Jacobson)
On peut donc avoir un même objet qui se comporte différemment selon son état (créé, initialisation 1 réalisée, initialisation 2 réalisée, prêt, en service, en erreur, ...).
L'utilisation des machines à états n'est pas une bidouille, mais une modélisation très formelle (que je recommande fortement).
3) d'après le titre : pour des objet d'une même classe qui sont dans des états différents, on peut avoir des réponses différentes à un même message. Tous les objets d'une même classe ont le même cycle de vie, donc sont décris par la même machine à état.
cf. point 1 de ce message et message d'ego : que veut dire pour toi "comportement" ? (réponse possible à un message OU cycle de vie complet sous forme de machine à états).
Quand je parlais de bidouille, j'ai un peu exagéré.
Il n'ya pas de méthodes (je sais c'est effrayant mais c'est comme ça), le comportement est modélisé avec les machines à états.
J'ai essayé avec l'héritage mais là encore ça bloque :aie:
alex00 : Pour moi, le comportement est un cycle de vie complet sous forme de machine à états en réponse à un message. donc le point1.
Disons que ma classe A à plusieurs modes de fonctionnements.
Selon le mode, un cycle de vie différent : La réponse à un même message sera différente suivant le mode dans lequel on se trouve.
Evidemment, le mieux serait de faire dériver cette classe par des classes B, C, D qui contiendrait chacune le comportement (la machine à états) pour un seul mode.
C'est tordu mais le problème c'est que le diagramme d'architecture est déjà énorme. Si il faut que je rajoute une classe pour chacun des modes, je multiplie d'autant les liaisons. J'ai l'impression de m'embrouiller de plus en plus là :roll:
Milk-at ... vu ! on me l'a fait tout le temps :mouarf:
Au lieu de théoriser, si tu nous montrais ce que tu as fait ?
je suis d'accord avec ego, se serait plus facile si on en voyait un peu plus ...
En tout cas il y a quelque chose que je ne comprends pas : pourquoi la/les machine(s) à états ne suffise(nt) pas et tu y attaches des classes annexes par mode ?
si tu as beaucoup d'états, utilise le pattern state (cf. http://pcaboche.developpez.com/artic...page=page_2#L2)
ce n'est pas tordu.
les liaisons (je comprends attributs et associations) sont toutes mises une seule fois au niveau de UneClasse (ou déléguées dans une structure de données UneClasseData)
Un diagramme d'architecture (ou de conception) n'a jamais à être complet : il vaut mieux faire plusieurs vues (ex : une d'ensemble avec UneClasse et ses liaisons, une autre qui détaille UneClasse et ses classes-états).
http://img149.imageshack.us/img149/826/img037lt.jpg
Donc on a un système modélisé par un ensemble de classes qui composent la classe principale Main.
Les Class1, Class2, …. ont des rôles subalternes et je l’ai juste mises pour montrer qu’elles existent.
La classe gestion recupère toutes les infos de configuration du système, entre autre les infos sur le mode dans lequel on se trouve. Qu’elle transmet à la classe application.
Les SousModule sont chargés de différentes opérations, chacune étant caractérisés par une fonction gloable (décision, traitement, exécution, récupération de données).
L’architecture gloable du système a été défini avant que je n’arrive sur le projet, donc je ne connais pas exactement tous les comment et pourquoi de ce choix de modélisation.
Donc, ce que j’essaye de faire, c’est que la classe d’application change de mode et le répercute sur tous les sous-modules.
Donc à partir de là, plusieurs solutions :
1) dans le diagramme de la machine à états, suivant le mode où l’on se trouve, la réaction à l’arrivée d’un même message sera différente. Et tout sera inclus dans la même machine à états, donc un critère de choix à placer avec l’arrivée de chaque message (y en a une cinquantaine).
http://img526.imageshack.us/img526/8650/img019je.jpg
2) L’héritage, une classe Sous Module est parente de N classes pour N modes. Dans chaque classe fille, un comportement différent avec la même structure physique (pour les ports entre autre).
http://img526.imageshack.us/img526/8262/img025rs.jpg
Pour l’instant mon problème avec cette solution , c’est que même si je crée la class avec New herit1() (avec le langage d'action dans Tau-G2)
Lorsque je simule, je me retrouve à suivre la machine à états de la classe mère.
bruno_pages : c'est un point que je ne contrôle pas, pour moi, j'aurais tout mis dans la même classe et bye bye
mais mes responsables tiennent à ce qu'il est y est une classe pour un mode de façon, je cite " à pouvoir rajouter facilement un mode si besoin est" :P
alex00 effectivement, j'avais oublié ce détail mais reste quand même la création des classes qui prend quand même un certain temps (le simple copier-coller ne marche pas).
Alors, j'ai regardé le pattern state ; j'arrive pas à voir si ça marche avec juste les machines à états ?
Je ne comprend pas tout mais bon.........
N'es-tu pas dans un système complexe qui comporte différentes parties, chacune réalisant un boulot particulier ?
Ces parties ont un comportement qui dépend d'un état "global" du système.
Quand il y a un changement d'état, il faut en avertir les différentes sous-parties qui vont réagir en conséquence.
Si j'ai bon, je ne suis pas certain qu'un seul diagramme d'états-transitions soit suffisant, il faut en faire un par sous-partie.
Le "vrai" diagramme d'état de ton système étant la somme des diagrammes d'états des sous-parties; c'est le cas dans un système complexe; prend le cas d'une voiture avec, le moteur, la climatisation, son GPS,...Dans le cas de la voiture, le diagramme d'état de la voiture ne peut être qu'une somme de diagrammes sachant qu'il peut y avoir des évènements au "niveau de la voiture" qui ont un impact sur les sous-éléments pré-cités (genre contact éteint).
Dernier point, ton archi n'est-elle pas issue de la mise en place du pattern "Blackboard" ?
En espérant avoir donné des idées utiles........
Je suis 100% d'accord avec egoCitation:
Envoyé par ego
Par contre je suis 100% contre l'utilisation du pattern state qui simule un changement de classe, car cela c'est vraiment un choix à la shadock
Désolé pour le temps de réponse, j'étais pas dans le coin.
Donc depuis mon message de mercredi, j'ai réussi à mettre en place la solution de l'héritage et pour l'instant ça tourne. 8-)
Donc pour le patern state, je penses que je vais faire sans.
Pour le pattern "Blackboard" , en réalité, je ne sais même pas de quoi il s'agit, donc si c'est ça, c'est pas fais exprès. :)
Il s'agit bien d'un système complexe dont le comportement de chaque partie dépend de l'état global et qu'il faut transmettre (messages).
Il y a bien un diagramme par sous-partie. le problème était de changer de "version" de sous-partie suivant le mode, ce que j'ai fais avec l'héritage.
Donc merci pour ces remarques ego et tous les autres.
Si il n'y a pas d'autres remarques, je pense que je pourrais appuyer sur le magnifique et tant désiré bouton "résolu".