J'ai un exercice qui nous demande de fournir un diagramme UML pour ce qui suit :
Un étudiant peut être un travailleur. Un travailleur peut aussi être un étudiant. Comment faire ?
C'est ma solution, mais je comprends que ce n'est pas efficace :
Une solution possible serait la suivante : 
Cette solution ajoute une classe supplémentaire pour le cas où un étudiant serait en même temps un travailleur.
Première mise à jour
L'image suivante montre comment StudentWorker peut hériter de Worker y Student bien que cela ne soit pas possible dans tous les langages de programmation et que cela puisse conduire à l'utilisation de l'option Le problème du diamant .
Deuxième mise à jour
Cette solution ne fait appel qu'à l'implémentation d'interfaces :
Veuillez noter que vous avez toujours besoin de 3 classes. Student y Worker mettent en œuvre deux interfaces chacun, le StudentWorker implémente les trois interfaces. Cela fait de ces trois classes une Person ainsi qu'un Student un IStudent , a Worker un IWorker et un StudentWorker un IStudent et un IWorker . J'espère que cela vous aidera ou vous donnera une idée sur la façon de créer votre solution individuelle.
L'étudiant et le travailleur seront tous deux des sous-classes de la classe Person. Person aura les attributs communs qui sont communs (nom et prénom). L'étudiant aura les notes scolaires et le travailleur aura le salaire.
C'est ainsi que vous pouvez représenter l'héritage en UML :
Vous avez une superclasse, et vos classes dérivées. Puisque votre superclasse est abstraite, elle aura des méthodes qui sont déclarées sans implémentation, vous les implémenterez dans vos classes Student et Worker (si vous le devez).
Si vous avez une autre classe student-worker, elle héritera à la fois de student et de worker. Ce sera donc quelque chose comme ceci :
A est votre classe abstraite Person, B et C sont respectivement Student et Worker, tandis que D est StudentWorker. StudentWorker hérite des attributs de Student et de Worker.
Ceci peut ou non être une réponse à votre exercice. Si j'avais ces exigences dans le monde réel, je les remanierais. (Bien sûr, dans le monde réel, j'aurais également beaucoup de questions sur les raffinements et les détails supplémentaires). La situation dans le monde réel est (on peut le supposer) que nous avons affaire à des personnes qui ont toujours un nom et un prénom. Puisque les noms et prénoms ne changent pas (on peut aussi le supposer) lorsque la personne est spécialisée dans des sous-classes, il n'y a aucune raison de fournir un moyen de les implémenter différemment dans les sous-classes. Il n'y a donc aucune raison de rendre la classe person abstraite, puisque c'est pour cela que l'on fait des classes abstraites.
C'est également une situation où l'agrégation (une classe "a" d'autres classes) est plus logique que l'héritage (une sous-classe "est" une super-classe). Je restructurerais donc les exigences de cette façon :
Personne : Nom, prénom Étudiant : École, notes Travailleur : Salaire
La classe Person peut "avoir" de zéro à une classe Student. La classe Personne peut "avoir" de zéro à une classe Travailleur.
Le fait que Person doive être abstrait implique également qu'une personne doit être soit un étudiant, soit un travailleur, soit les deux. Cela peut être spécifié par un or contrainte entre les deux classes.
Voici un schéma :
La classe Personne a une relation d'agrégation avec les classes Étudiant et Travailleur. Une classe de personne peut avoir de zéro à une classe d'étudiant. Une classe de personne peut également avoir de zéro à une classe de travailleur. Le site {or} La contrainte précise en outre qu'il doit y avoir un étudiant ou un travailleur, ou un de chaque.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
