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'éxé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 !

[Mat007]

Salut,

Je pense que quelque chose qui ne sert à rien il ne faut pas le mettre (ou il faut le retirer) : autant éviter d'alourdir...

Sinon comme je suis un fervent partisant de la conception orientée traitements (par opposition à orientée données), le diagramme de classe me laisse de marbre, il manque de toute façon un diagramme de séquence pour voir vraiment ce qu'il se passe... Cela dit si les seules méthodes sur ces classes sont des accesseurs c'est pas forcément la peine, mais c'est pas vraiment de la conception à ce moment-là

MAT.

[millie]

Est-ce complètement débile d'hériter sans rajouter d'attribut ou de méthodes?

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 cuire 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.

J'avais eu le même type de problème dans la conception d'un projet, j'avais en gros un diagramme de classe comme ça (je ne suis pas sûr que le lien tienne le coup longtemps).

Je suis désolé de la grosseur du diagramme, c'est à cause du Clonable




Par exemple, au niveau de AreaOperator, on voit 5 fistons. Les codes des fils sont ultra court :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class ConvolveOperator : public AreaOperator
  {
    public:
 
      /**
       * @brief créer un opérateur de convolution à partir d'un noyau
       *
       * @param k le noyau
       */
      ConvolveOperator(const Kernel& k) :
          AreaOperator(ConvolveLocalOperator(k))
      {}
 
     /**
      * clone
      */
      ConvolveOperator * clone() const
      {
        return new ConvolveOperator(*this);
      }
  };

Mais pour l'utilisateur de la classe, ça devient extremement plus simple.
Il n'a pas à se soucier que c'est un opérateur de type AreaOperator.
A noter que ça permet de casser un peu l'architecture sans que les utilisateurs aient à changer leur code (si il n'utilise pas les classes intermédiaire du type AreaOperator ou PointOperator)

Maintenant, ça doit dépendre de pas mal de chose.

[poukill]

Merci Mat007 et Millie pour vos réponses.

@Mat : La conception orientée traitement, je ne vois pas spécialement ce que c'est. Je comprend bien orienté Objet et orientée données (son contraire), mais orientée traitement ça ne me dis rien...

@Millie: Je vois très bien ce que tu veux dire. Dans ton cas ConvolveOperator est pleinement justifié car permet se sortir de l'abstraction AreaOperator... Dans mon cas c'est un peu moins évident, quoique Materiau est suffisamment général pour le spécialisé un peu...

Ce que je voulais éviter, c'est surtout l'erreur du débutant qui va faire hériter San Francisco de Ville, alors que San Francisco n'est qu'une instance à l'éxécution de Ville...
Avec un peu de recul, je ne pense pas que ce soit le cas pour moi, mais des avis extérieurs sont importants pour me conforter dans ma décision!


Donc a priori je vais rester comme ça, avec cet héritage de sous-type.

Merci !