Salut, j'étudie des trucs basiques, et là je comprend pas qqch.

Imaginons une classe Personne. Imaginons également une classe Avion, une classe Voiture, une classe Bateau.

La personne qui conduit un Avion s'appelle un pilote, celle qui conduit une Voiture un conducteur, celle qui conduit un Avion un capitaine. Chacune des classes correspondant à ces véhicule est donc associée avec une Personne (ou classe héritée de Personne).

Mon prof propose trois alternatives :

1. Rôles sur association : l'association porte directement avec une personne. Ne permet pas de spécifier des attributs ou méthodes propre au rôle du conducteur.

2. Spécialisation : on fait hériter de Personne une nouvelle classe Pilote, qui possède des attributs spécifiques aux pilotes d'avions, et ainsi de suite pour chaque type de véhicule. Ce sont ces classes spécialisées qui sont associées avec les véhicules correspondants. Permet de spécifier des attributs/méthodes propre à chaque conducteur, mais interdit les rôles multiples et dynamiques (qu'est-ce que cela veut dire, d'ailleurs?

3. Classes de rôles : là je comprend plus rien. On a une classe abstraite RoleDePersonne, qui est associée avec une Personne. De la classe RoleDePersonne héritent des classes spécialisées comme au point 2 (Pilote, Conducteur, Capitaine), et ces dernières sont associées avec les véhicules appropriés. Il est dit que cette dernière technique permet les rôles multiples et dynamiques...

Merci beaucoup de votre aide, je suis complètement dans le brouillard

La solution 3 permets plus de possibilités non ?

On a :

Interface -> Abtract -> Classe

L'interface permets de définir les méthodes qui devront être implémentés si une classe en hérite.
La classe abtract permets de définir des variables communes aux classes qui en héritent et un comportement par défaut pour certaines méthodes si nécessaire.
Les classes définissent uniquement les variables membres/functions qui sont uniques à leur spécialité

Dans le 1, tu as juste une classe qui serra la même pour tout les roles (pas pratique)

Dans le 2, tu as classe -> classe, donc les méthodes spécialisés des différents pilotes devront être définie dans la classe des pilotes donc tu pourra pas les stocker en tant que simple personnages, tu devra à chaque fois préciser le type, c'est ce qu'il entends par non dynamique je crois
(ou alors tu défini les méthodes spécialisées aussi dans personnage, mais c'est pas très clean)

Les 3 marchent mais la 3ème est plus modulable est pratique.

Bonsoir,

Je vais te dire pourquoi tu es dans le brouillard : ni moi, ni toi, n'avons compris la question. Avant de philosopher sur une solution technique, il faut déjà déterminer clairement les fonctionnalités que ton code va devoir fournir. Une fois que ce sera fait, on pourra se pencher sur la technique... mais pas avant.

Merci pour vos réponses.

Vis1teur : je suis d'accord que les trois fonctionnent, mais je comprend pas ce que le 3. apporte de plus par rapport au 2, étant donné qu'au final ce sont quand même des classes spécialisées ( Pilote, Capitaine et Conducteur) qui sont associées aux véhicules correspondants...

Chris27 : En effet, je n'ai pas compris quelque chose dans le fonctionnement du modèle proposé, c'est d'ailleurs bien pour ça que je suis là. Comme c'est un exemple d'architecture il n'y pas de code dans l'exemple de mon prof, que je retransmet d'ailleurs tel qu'il est...(l'exemple, pas le prof). Je peux toujours inventer les fonctionnalités dont tu parles :

On a un programme dans lequel des voitures, des avions et des bateaux sont modélisés. Disons que c'est un programme qui enregistre les historiques des voyages de tous ces véhicules. Dans ces historiques ont enregistre le conducteur du véhicule, qui est TOUJOURS une personne, mais qui, pour chaque véhicule, possède des attributs différents (enfin, on aimerait que ce soit le cas du moins).

Ici on se propose de donner un diagramme de classes (juste associations et héritages) qui résume la partie véhicules-conducteurs.

Ma question est : qu'apporte la version 3 par rapport à la version 2?

Si je ne suis pas assez clair, dites-moi et je peux dessiner les 3 diagrammes correspondants aux 3 points...

Merci

En regardant de très très loin, je dirais :

2 = caca

3 = il y a le mot clé "classe abstraite" = enfin de la vraie POO.

Après, il faut vraiment voir à l'usage si tu as besoin d'abstraire. Si oui, la solution 3 est sans doute la seule qui tienne la route. Si non, il ne fallait probablement pas faire de POO du tout, mais opter pour la solution 0.

Mais en quoi la classe abstraite apporte-t-elle quelque chose dans ce cas puisqu'au final on est quand même obligé de créer une classe spécialisée dépendant de Personne ?

...une classe spécialisée dépendant de Personne [pour chaque type de conducteur] ?

Désolé du double post

+ un jour on aura la fonction edit, j'y crois

Je vois les choses dans l'autre sens. L'intérêt réel de l'orienté objet, c'est l'extensionalisme qu'apporte les classes abstraites.

Sur ton exemple, le soucis avec la méthode 2 c'est que si tu veux ajotuer un Chauffeur (de camion), tu dois faire un (voire plusieurs) nouvel héritage ET modifier les types et/ou certains appels de méthodes partout dans le code. Avec la méthode 3, l'interface abstraite fait que les particuliers du Chauffeur (du Pilote, du Conducteur, etc.) sont masquées. Donc la seule chose à faire est de coder le nouvel héritage.

Je ne comprend pas :

Les classes spécialisées de conducteurs ont des attributs et des méthodes distinctes (de signatures distinctes)(par exemple, au bol, les pilotes ont un attribut booléen " certificatAterrissage " ) ==> dans ce cas il faut de toute façon modifier des choses partout dans le code

Bien sûr il y a une partie, modélisée par la classe abstraite ou l'interface, qui définit un groupe de méthodes et d'attributs que doivent obligatoirement implémenter toutes les classes spécialisées, et pour cette partie il n'y a rien besoin de changer dans le code. Mais pour tout ce qui fait la particularité des conducteurs, la classe abstraite ne sert à rien, et je ne vois pas ce qu'elle apporte par rapport à un héritage direct de Personne.

Désolé d'être lent à comprendre...

Ôte moi d'un doute ? Tu ne coderais pas en Java par hasard ?

"3. Classes de rôles : là je comprend plus rien. On a une classe abstraite RoleDePersonne, qui est associée avec une Personne. De la classe RoleDePersonne héritent des classes spécialisées comme au point 2 (Pilote, Conducteur, Capitaine), et ces dernières sont associées avec les véhicules appropriés. Il est dit que cette dernière technique permet les rôles multiples et dynamiques... "

Ce que je comprends de cette solution est la possibilité pour une personne d'être affectée à différents rôles. Ainsi une personne peut être tantôt un Pilote, un Conducteur ou un Capitaine, sans que ça n'impacte le code.

"Les classes spécialisées de conducteurs ont des attributs et des méthodes distinctes (de signatures distinctes)(par exemple, au bol, les pilotes ont un attribut booléen " certificatAterrissage " ) ==> dans ce cas il faut de toute façon modifier des choses partout dans le code "

Pour définir RoleDePersonne il faut parvenir à faire abstraction des spécificités d'implémentation de chacune des classes spécialisées, afin d'extraire un ensemble de méthodes communes à tous les rôles de personnes : en gros qu'attend-t-on précisément d'un RoleDePersonne ?
On peut par exemple imaginer que l'interface RoleDePersonne puisse exposer une méthode allerA(destination : Point), et chaque implémentation de RoleDePersonne doit implémenter la fonction allerA en fonction du moyen de transport considérer.

Chris27 : je ne code pas dans le cadre de ce cours...

Aldebran : Ok, il y a un "tronc commun" pour tous les rôles. Mais dans le cas où certains rôles font des choses que d'autres ne peuvent pas, ou encore que certains rôles possèdent des attributs qui n'ont pas lieu d'être sur d'autres, en quoi avoir une classe abstraite nous aiderait-il, puisqu'au final on se retrouve à devoir utiliser explicitement des classes spécialisées ?

(Je suis Conchoide... )

"Aldebran : Ok, il y a un "tronc commun" pour tous les rôles. Mais dans le cas où certains rôles font des choses que d'autres ne peuvent pas, ou encore que certains rôles possèdent des attributs qui n'ont pas lieu d'être sur d'autres, en quoi avoir une classe abstraite nous aiderait-il, puisqu'au final on se retrouve à devoir utiliser explicitement des classes spécialisées ?"

Si l'interface de RoleDePersonne ne convient pas car tu as besoin d'accéder à des méthodes spécifiques pour chaque rôle, alors il faudra revoir entièrement ton architecture. L'interface RoleDePersonne ne doit être utilisée que dans un cadre où les rôles sont interchangeables et où seules les méthodes définies par RoleDePersonne seront utilisées.

Ok là c'est plus clair. Merci à tous