-
Notifications
You must be signed in to change notification settings - Fork 0
Explication des classes
Ben edited this page Jan 13, 2025
·
2 revisions
- Héritage : herbivore et Carnivore héritent de Animal.
- Association :
- Animal est composé de Tete, Corps, Membres et est associé à un Habitat.
- La relation est représentée avec losange noir pour indiquer la composition, sauf pour Habitat (association classique).
- composition
- utilisée pour les relations entre Animal et ses parties internes (Tete, Corps, Membres).
Une composition signifie que les objets associés ne peuvent exister indépendamment de l’objet principal. Si l’Animal est détruit, ses parties associées (Tete, Corps, Membres) le sont également. Une relation "forte" et nécessaire, comme dans la vraie vie : un animal ne peut pas exister sans une tête ou un corps.
- Impact sur l'implémentation :
- Ces objets sont crées dans le constructeur de Animal ou passés directement comme arguments, mais ils dépendent fortement de Animal
- Une cardinalité obligatoire (1..) impose la validation stricte que ces éléments ne soient jamais None.
-
Agrégation
- Non utilisée ici, mais pourrait être pertinente pour représenter des relations où les objets peuvent exister indépendamment.
- Exemple : Si les Membres devaient indépendants, alors une agrégation (au lieu d'une composition) serait plus adaptée.
- Différence avec la composition :
- Dans une agrégation, les objets agrégés peuvent vivre indépendamment de l’objet principal. Par exemple, un Membre pourrait exister sans être attaché à un Animal.
- Impact sur le code :
- Au lieu de créer les objets dans le constructeur de Animal, ils peuvent être créés ailleurs et passés comme paramètres sans lien d’exclusivité.
-
Association simple (flèche) :
- Utilisée pour la relation entre Animal et Habitat.
- Pourquoi ?
- Un Habitat peut exister indépendamment d’un Animal. Plusieurs animaux peuvent partager un même habitat (cardinalité 1..*).
- Impact sur l’implémentation :
- Les objets Habitat sont créés séparément et associés à un Animal.
- On peut avoir un attribut de type référence (self.habitat), mais cela ne nécessite pas de contrôle aussi strict que la composition.
- Composition :
- Les objets dépendants (Tete, Corps, Membres) sont créés ou passés au constructeur de l’objet principal (Animal), et leur existence est subordonnée à celle de cet objet principal.
- Exemple d’implémentation :
class Animal:
def __init__(self):
self.tete = Tete("ronde", "grande") # Créé directement ici.- Agrégation :
- Les objets agrégés sont créés en dehors de l’objet principal et lui sont associés. Ils peuvent exister indépendamment de celui-ci.
- Exemple d’implémentation :
class Animal:
def __init__(self, tete):
self.tete = tete # Référence à un objet existant.
tete_independante = Tete("ronde", "grande")
animal = Animal(tete_independante)- Cardinalité Obligatoire (1..1 ou 1..*):
- Code :
- Valider dans le constructeur que l’attribut est toujours présent (pas None).
- Exemple :
- Code :
if not isinstance(tete, Tete):
raise ValueError("tete doit être une instance de la classe Tete")- Cardinalité Optionnelle (0..1 ou 0..*):
- Code :
- Les attributs peuvent être None si la cardinalité est 0..1.
- Exemple :
- Code :
class Animal:
def __init__(self, membres=None):
self.membres = membres or [] # Valeur par défaut si None. * Dans le cas de listes, vérifier que l’attribut est vide ([]) si aucune instance n’est associée.
- La composition est utilisée pour des relations "fortes" et nécessaires, comme Animal et ses parties (tête, corps, membres), car ces éléments ne peuvent exister séparément.
- L’association est utilisée pour des relations plus "faibles", comme Animal et Habitat, où chaque objet peut exister indépendamment.
- L’agrégation pourrait être utilisée si certains objets (comme des membres) devaient être indépendants ou partagés.
- Héritage : Professeur et Eleve héritent de Personne.
- Association :
- Classe est liée par agrégation à Professeur et Eleve. Personne est associée à un Dossier.
- La relation est représentée avec un losange vide pour indiquer l'agrégation, sauf pour Personne et Dossier (association classique).
- Agrégation
- Utilisée pour les relations entre Classe et Professeur, Eleve.
Une agrégation signifie que les objets associés peuvent exister indépendamment de l’objet principal. Si la Classe est détruite, ses parties associées (Professeur et Eleve) ne le sont pas. C’est une relation "faible", qui reflète la réalité : une classe peut exister sans élèves (par exemple, la classe reste une structure, même si elle n’a pas encore d’élèves affectés). De même, un élève peut faire partie de plusieurs classes sans que la destruction d'une classe n'affecte l'élève.
- Impact sur l’implémentation :
- Au lieu de créer les objets Professeur et Eleve dans le constructeur de Classe, ils peuvent être créés ailleurs et passés comme paramètres à la Classe. Cela permet de partager un même Professeur entre plusieurs classes et d'affecter un même élève à plusieurs classes sans créer de lien exclusif.
- Association simple (flèche) :
- Utilisée pour la relation entre Personne et Dossier.
- Pourquoi ?
- Dans cette situation, j'ai considéré qu'un Dossier peut exister indépendamment d’une Personne. Dans le monde réel, une personne qui quitterait l'école pourrait toujours avoir son dossier enregistré dans celle-ci (par exemple, pour garder une trace administrative ou pour une réinscription future). Le Dossier est lié à la Personne, mais sa gestion n'est pas directement liée à la durée de vie de la Personne.
- Impact sur l’implémentation :
- Les objets Dossier sont créés séparément et associés à une Personne par l'intermédiaire du constructeur. La relation entre les deux est une simple association, ce qui signifie qu'un Dossier peut être réutilisé indépendamment d'une Personne.
- Composition :
Si j'avais utilise une composition plutot qu'une simple association :
* Dans le cas de la composition, l'objet contenu (par exemple, un objet Dossier) est créé et géré par l'objet principal (Personne). Si l'objet principal est détruit, l'objet contenu est également détruit. La durée de vie de l'objet contenu est directement liée à celle de l'objet composite.
* Exemple dans le code :
class Personne:
def __init__(self, dossier: Dossier):
self.dossier = dossier # Si Personne est détruite, son Dossier l'est aussi.- Agrégation :
- Dans l'agrégation, l'objet contenu (par exemple, un Professeur ou un Eleve) peut exister indépendamment de l'objet principal (Classe). La durée de vie de l'objet contenu n'est pas liée à celle de l'objet qui l'agrège. L'objet contenu peut être réutilisé dans différents contextes.
- Exemple dans le code :
class Classe:
def __init__(self, professeur: Professeur, nom_classe: str):
self.professeur = professeur # Agrégation : Professeur peut exister indépendamment de la Classe.
self.eleves: List[Eleve] = [] # Agrégation : Élèves peuvent exister indépendamment de la Classe.La cardinalité définit le nombre d'instances d'une classe pouvant être liées à une autre classe dans une relation donnée. Par exemple, dans le cas de la classe Classe :
- Une Classe peut avoir un seul Professeur et plusieurs Eleves. Cela reflète une cardinalité de 1..1 pour Professeur et 0..* pour Eleve. Le professeur est associé à une seule classe, tandis qu'un élève peut appartenir à plusieurs classes (selon la gestion de l'école).
- Impact sur le code : La classe Classe contient une seule instance de Professeur et une liste d'instances de Eleve, et cela permet de gérer les associations respectivement de manière un-à-un et un-à-plusieurs. Il n’y a pas de restriction qui empêche de changer le professeur d’une classe ou de déplacer un élève d’une classe à une autre.
- L'agrégation est utilisée pour des relations "faibles" et partagées, comme entre Classe et Professeur ou Eleve, car ces objets peuvent exister indépendamment et être partagés entre plusieurs classes ou contextes.
- L'association est utilisée pour des relations simples, comme entre Personne et Dossier, où chaque objet peut exister séparément mais est lié à l'autre de manière non exclusive.
- La composition n'est pas utilisée dans ce cas, car il n'y a pas de relations "fortes" nécessitant une gestion exclusive de la durée de vie des objets associés.
- Composition : AdresseEmail, TexteEmail et FichierJoint sont liés par composition à Email.
- Composition :
- Utilisée pour les relations entre Email et ses composants : AdresseEmail, TexteEmail, et FichierJoint.
Une composition signifie que les objets associés sont essentiels à l'objet principal et ne peuvent exister indépendamment de celui-ci. Par exemple, un Email ne peut pas exister sans AdresseEmail (expéditeur, destinataire), sans TexteEmail (le contenu de l'email) et sans FichierJoint (les pièces jointes). Si un Email est détruit, ses composants (comme l'adresse email, le texte ou les fichiers joints) le sont également.
* Impact sur l’implémentation :
* Les objets AdresseEmail, TexteEmail et FichierJoint sont créés et gérés dans le constructeur de Email. Cela garantit que chaque email a une adresse valide, un contenu textuel et éventuellement des fichiers joints. Leur existence est directement liée à celle de l'email.
- Composition :
- La composition est utilisée ici pour indiquer que les objets comme AdresseEmail, TexteEmail et FichierJoint ne peuvent exister sans un Email. Ils sont créés et gérés par le Email, et leur durée de vie dépend de celle de l'email.
- Exemple dans le code :
class Email:
def __init__(
self,
expediteur: str,
destinataire: str,
titre: str,
corps: str,
fichiers: List[FichierJoint] = None # Fichiers joints sont optionnels
):
# Composition
self.expediteur = AdresseEmail(expediteur)
self.destinataire = AdresseEmail(destinataire)
# Composition
self.texte = TexteEmail(titre, corps)- Agrégation :
- L'agrégation n'est pas utilisée ici, car les composants d'un email (comme les fichiers joints ou le texte) ne sont pas destinés à être partagés entre plusieurs emails. Leur existence est totalement liée à l'email auquel ils appartiennent.
- Si nous avions une situation où les fichiers joints devaient être partagés entre plusieurs emails, alors l'agrégation aurait été plus appropriée. Par exemple, un même fichier joint pourrait être ajouté à plusieurs emails sans être détruit lorsque l'email est détruit.
La cardinalité définit combien d'instances d'un objet peuvent être liées à un autre objet dans une relation. Par exemple, dans le cas de Email :
- Un Email peut avoir un expéditeur et un destinataire (cardinalité 1..1 pour ces relations), ainsi qu'un ou plusieurs fichiers joints (cardinalité 0..* pour FichierJoint).
- Impact sur le code : La classe Email contient une seule instance de AdresseEmail pour l'expéditeur et le destinataire, une instance de TexteEmail pour le contenu de l'email, et une liste d'instances de FichierJoint pour les fichiers joints. Cela permet de gérer ces associations de manière un-à-un pour les adresses et le texte, et un-à-plusieurs pour les fichiers joints.
- La composition est utilisée ici pour des relations "fortes" et nécessaires, comme entre Email et ses composants (AdresseEmail, TexteEmail, FichierJoint), car ces éléments ne peuvent exister sans l'email et leur durée de vie dépend de l'email.
- L'association n'est pas utilisée, car chaque objet est géré de manière stricte par l'email lui-même.
- L'agrégation ne s'applique pas dans ce contexte, car les composants de l'email ne sont pas partagés ou réutilisés ailleurs.