Discussion :

[poukill]

Bonjour à tous!
J'essaye depuis quelque temps, de m'approcher de ma meilleure conception possible dans mon cas...
J'arrive au diagramme suivant : (pièce jointe)

Est-ce complètement débile d'hériter sans rajouter d'attribut ou de méthodes?
Les classes en question (CFC, Cuivre, Inox) ne sont elles que des instances à l'exécution?

Il est possible (question de réutilisabilité) que des choses soient rajoutées à la suite propre à certains matériaux... C'est pourquoi je suis parti sur cette voie.
De plus, certains paramètres pourraient être mis par défault dans les constructeurs...

Dites moi ce que vous en pensez...

Merci !

[Hephaistos007]

Je pense que tu confonds ici les mécanismes d'héritage et d'instanciation. L'héritage possède la sémantique "EST-UNE-SORTE-DE" alors que l'instance possède la sémantique "EST-UN".

Cuivre EST-UN Matériau,
Inox EST-UN Matériau,
Matériau_fissible EST-UNE-SORTE-DE Matériau,
Matériau_non_fissible EST-UNE-SORTE-DE Matériau,
....

Cuivre et Inox sont des instances (objets) de la classe Matériau, mais certainement pas des classes. La meilleure preuve est que tu t'inquiètes de ne pas trouver quelles propriétés y ajouter

[poukill]

Cuivre et Inox sont des instances (objets) de la classe Matériau, mais certainement pas des classes. La meilleure preuve est que tu t'inquiètes de ne pas trouver quelles propriétés y ajouter

Complètement d'accord avec toi...
Depuis j'ai effectivement rajouté une arborescence : Metaux, Fluide, etc...
L'Inox est un métal, certes. Mais ce qu'il faut voir, c'est est-ce que l'héritage apporte quelque chose en plus? De nouveaux attributs, de nouvelles méthodes?

Je connais bien l'erreur de débutant qui consiterai à faire hériter Paris de Ville, alors que Paris n'est qu'une instance de la classe Ville à l'éxecution... Celà dit, ça dépend de la granularité avec laquelle on regarde : s'il y a des choses à rajouter à Paris et rien qu'à Paris (Tour Effeil, etc...), alors Paris serait bien une classe, et Ville plutôt une classe abstraite...

Dans mon cas, je dirai que le matériau est étudié au sens physique, avec ses propriétés. J'ai choisi de placer Matériau en classe abstraite, et d'introduire Métaux, Fluide et Dépôts. De là je fais dériver Cuivre, Inox de Métaux.
Ici se repose le même problème : est-ce une bonne idée? Là encore ne sont-ce pas des instances?
Je pense que:
1) Des propriétés peuvent arriver par la suite (c'est pas moi le physicien, alors...)
2) Les constructeurs par défault pourrait initialiser les membres avec des valeurs pas défault bien pratique pour l'utilisateur (température de fusion du cuivre). -> simplification !
L'utilisateur n'a pas à se préoccuper qu'il s'agisse d'un Matériau, il manipule son objet en cuivre...
Pour cette remarque, voir le post (le même que j'ai voulu déplacer moi-même mais c'est pas possible ! ) ICI

Merci pour ton aide...

Je pense garder ces Cuivre, Inox, etc...

[Hephaistos007]

Je connais bien l'erreur de débutant qui consiterai à faire hériter Paris de Ville, alors que Paris n'est qu'une instance de la classe Ville à l'éxecution... Celà dit, ça dépend de la granularité avec laquelle on regarde : s'il y a des choses à rajouter à Paris et rien qu'à Paris (Tour Effeil, etc...), alors Paris serait bien une classe, et Ville plutôt une classe abstraite...

Encore non, car :

• Cela contredit la sémantique des relations que je t'ai donné et qui sont des guides pour une bonne conception. Tu pourras retourner le problème dans tous les sens, "Paris EST-UNE-SORTE-DE Ville" sera toujours faux.
• Ensuite, pour reprendre ton exemple, tu refais la même erreur mais au niveau des attributs cette fois-ci. "Tour effeil" est clairement une instance d'un attribut "monument" par exemple. Voici une conception correcte (pseudo-code) :
  
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  classe Ville {
  nom;
  }
  
  classe VilleTouristique hériteDe Ville {
  monument;
  }
  
  /* instanciation */
  VilleTouristique p = new VilleTouristique("Paris", "Tour Eiffel");

[Hephaistos007]

J'ai choisi de placer Matériau en classe abstraite, et d'introduire Métaux, Fluide et Dépôts.

BIEN !

De là je fais dériver Cuivre, Inox de Métaux.
Ici se repose le même problème : est-ce une bonne idée? Là encore ne sont-ce pas des instances?

PAS BIEN ! toujours la même remarque !

Cuivre EST-UN matériau, Inox EST-UN matériau, Huile EST-UN Fluide, etc.

[poukill]

Oui c'est vrai. Je plussoie, bien entendu...
Que penses-tu du post de
Millie sur le même sujet:

Comme tu l'as indiqué, il est possible d'ajouter des méthodes supplémentaires (même si ce n'est pas prévu actuellement, il faut penser au futur), genre : type de cuivre ou je ne sais pas quoi.

Ca peut également rendre la vie plus simple à l'utilisateur de ta classe. En effet, il pourrait avoir à utiliser un type Cuivre sans se soucier de la hiérarchie de classe.

En résumé :
-> utilisation du constructeur par défaut pour construire l'objet cuivre avec des valeurs pertinentes...
-> Simplification du diagramme pour le client.

C'est le seul truc qui me tire dans cette direction. Sinon, je suis bien d'accord avec toi que Cuivre ne devrait être qu'une instance de Metaux...
Mais n'a t-on pas le "droit" de rajouter des classes avec juste par convénience???

Merci pour tes commentaires

[koala01]

Salut,

Afin d'orienter la réflection, estimes tu *plausible* qu'au fil de l'évolution tu sois mené à considérer cuivre inox et autre non pas en tant que matériau, mais bel et bien pour ce qu'il sont: une matière

Selon moi, si tu estimes plausible d'envisager le cuivre comme une matière (métal non féreux, hautement conducteur) (par exemple) et non plus comme un matériau (j'utilise une bobine en cuivre pour le rotor de mon moteur), l'héritage peut se justifier...

Si, par contre, tu estimes que tu n'utiliseras jamais "cuivre" que comme une instance de matériau, l'héritage n'a pas lieu d'etre

[poukill]

Oui je crois que c'est exactement ça la question à se poser Koala... En passant quelques jours en tête à tête avec mes pensées, je pense effectivement qu'il faut voir si l'instance n'est finalement pas un objet lui-même...
Difficile à dire dans mon cas, surtout pour la gestion des évolutions.

De plus, le technique d'héritage est souvent utilisée de manière "abusive", alors j'ai pris le temps de réfléchir un peu... J'ai pas encore trouvé la solution, mais je suis maintenant sûr de me poser les bonnes questions !

Merci à toi !

[lapanne]

Salut,

Afin d'orienter la réflection, estimes tu *plausible* qu'au fil de l'évolution tu sois mené à considérer cuivre inox et autre non pas en tant que matériau, mais bel et bien pour ce qu'il sont: une matière

Selon moi, si tu estimes plausible d'envisager le cuivre comme une matière (métal non féreux, hautement conducteur) (par exemple) et non plus comme un matériau (j'utilise une bobine en cuivre pour le rotor de mon moteur), l'héritage peut se justifier...

Si, par contre, tu estimes que tu n'utiliseras jamais "cuivre" que comme une instance de matériau, l'héritage n'a pas lieu d'etre

+1 L'héritage ou instanciation sont des notions qui dépendent totalement du système que l'on souhaite modéliser.

Le conceptualisation dépend toujours de la sémantique que l'on souhaite apporter à une entité dans le cadre du système que l'on souhaite modéliser.

(ouuuuh la belle phrase )