Discussion :

[poukill]

Je suis pas sûr que ce soit le meilleur endroit pour poster ce topic, mais je pense qu'il a sa place ici...

Dans un but de réutilisabilité de mon code (et surtout pour encore améliorer sa clarté), je souhaite modifier tout mon programme pour l'orienter objet!
Seulement, le problème qui se pose à moi n'est pas technique, mais plutôt conceptuel...

En effet, mon problème ne se met pas en forme comme on a l'habitude de le faire: une classe client, une classe serveur, ou encore une classe temps, une classe date !
Bref, j'ai déjà du mal à définir mes limites!

Je me pose plusieurs questions:
1) Dans quels cas faire hériter une classe d'une autre?
2) Une classe avec une seule variable est-elle abbérante?
3) Une classe peut-elle contenir des données qui ne pas vraiment propre à elle? (exemple : dans mon cas, une classe Composant qui contiendrait une variable numero_experience...)

Bref, je vous remercie d'avance d'éclaircir ma lanterne.

[Swoög]

Salut

Alors, globalement les réponses seraient (à mon avis)

1°) Quand la seconde classe peut-être considérée comme étant la première avec des améliorations (exemple : un point coloré EST un point AVEC une couleur)

2°) Non, si la sémantique demande une classe, alors autant en mettre une

3°) Non... vaut mieux faire deux classes séparées (avec éventuellement l'une qui contient une instance de l'autre), la sémantique n'en souffrira pas au contraire

[poukill]

3°) Non... vaut mieux faire deux classes séparées (avec éventuellement l'une qui contient une instance de l'autre), la sémantique n'en souffrira pas au contraire

Une qui contient une instance de l'autre? C'est à dire? Avec un mécanisme d'héritage?

[Matthieu Brucher]

En fait, ça a sans doute plus sa place dans conception, si ça te dit

C'est un exemple typique où il faudrait que tu lises un livre sur les design patterns et leurs applications à l'orienté objet. Il y a une critique de livre qui paraîtra mardi sur http://uml.developpez.com/livres/

[poukill]

En fait, ça a sans doute plus sa place dans conception, si ça te dit

Ok Miles, pas de problème...

class A
{
private :
B _instance_de_B;

[...]
};

Oui, of course (je suis fatigué aujourd'hui... )

[Swoög]

du style :

Code :

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

1
2
3
4
5
6
7
class A 
{
   private :
      B _instance_de_B;
 
   [...]
};

[poukill]

Salut

Alors, globalement les réponses seraient (à mon avis)

1°) Quand la seconde classe peut-être considérée comme étant la première avec des améliorations (exemple : un point coloré EST un point AVEC une couleur)

2°) Non, si la sémantique demande une classe, alors autant en mettre une

3°) Non... vaut mieux faire deux classes séparées (avec éventuellement l'une qui contient une instance de l'autre), la sémantique n'en souffrira pas au contraire

Je te pose directement mon problème:
Si je fais une classe Experience qui contient juste comme variable le numéro d'expérience:

Code :

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

1
2
3
4
5
6
7
8
 
class Experience {
private:
int num_experience;
 
public:
[...]
}

Et que ma classe Composant va TOUJOURS avoir besoin du numéro d'expérience, est-ce que je peux faire hériter Composant d'Experience???

Ou est-ce que c'est débile ?

[poukill]

Miles, il semble que du coup tu aies répondu à ma question!

[Matthieu Brucher]

Miles, il semble que du coup tu aies répondu à ma question!

Ah, génial
Pour ce genre de chose, regarde comme dit l'index de la rubrique UML mardi prochain

[poukill]

Ah, génial
Pour ce genre de chose, regarde comme dit l'index de la rubrique UML mardi prochain

Je regarderai...

Non, Composant, c'est un composant électronique, bref un truc physique!
Ca n'a rien à voir avec une expérience, même si chaque expérience nécessite un composant!

Donc c'est une instance Experience que je devrai mettre dans Composant, c'est bien ça?

[Matthieu Brucher]

Non, dans Experience, tu auras une instance de Composant - c'est quoi Composant pour toi ? -, car un composant n'est pas une expérience.

[Matthieu Brucher]

Je me pose plusieurs questions:
1) Dans quels cas faire hériter une classe d'une autre?
2) Une classe avec une seule variable est-elle abbérante?
3) Une classe peut-elle contenir des données qui ne pas vraiment propre à elle? (exemple : dans mon cas, une classe Composant qui contiendrait une variable numero_experience...)

Bref, je vous remercie d'avance d'éclaircir ma lanterne.

1) Une classe hérite d'une autre lorsque la nouvelle instance se comportera pour l'extérieur comme la première. Dans les autres cas, il faut voir du côté de la composition, par exemple.
2) Non, ce n'est pas abbérrant, mais s'il n'y a aucune méthode qui travaille dessus, oui Par exemple pour un refactopring que j'ai fait, j'ai encapsulé une std::map dans une nouvelle classe avec des méthodes pour l'utiliser comme une espèce de liste triée.
3) Normalement non, c'est à éviter. L'instance de la classe Composant devrait plutôt appartenir à une instance de Experience qui elle aura un numero_experience

[Nip]

Rapidement de mon cote:

1) Dans quels cas faire hériter une classe d'une autre?

On va partir du principe que tu parles de l'heritage d'implementation et dans ce cas je dirai jamais! Les raisons en vrac: rupture de l'encapsulation, couplage fort, semantique aleatoire, baisse de la flexibilite et complexite augmentee.
Les alternatives: interface et composition

2) Une classe avec une seule variable est-elle abbérante?

Comme Miles, un seul attribut dans la classe, pas abberant, mais une seule methode oui

3) Une classe peut-elle contenir des données qui ne pas vraiment propre à elle? (exemple : dans mon cas, une classe Composant qui contiendrait une variable numero_experience...)

Elle peut (tout) mais c'est pas bien mais la dessus les explications de Miles sont claires.

[Matthieu Brucher]

Ouf, j'ai presque pas tout faux

[poukill]

Merci à tous pour vos réponses!

Rapidement de mon cote:
On va partir du principe que tu parles de l'heritage d'implementation et dans ce cas je dirai jamais! Les raisons en vrac: rupture de l'encapsulation, couplage fort, semantique aleatoire, baisse de la flexibilite et complexite augmentee.
Les alternatives: interface et composition

Je suppose que tu parles là de deux classes bien différentes non???
Car j'ai jamais vu l'héritage de deux classes faire une rupture d'encapsulation
Mais bon, je suis loin de tout connaitre sur le sujet !

Je pourrai avoir juste un soupçon d'explications? Je potasse de mon côté un bouquin de C++!

Merci!

[Matthieu Brucher]

Si, en fait tu rompts l'encapsulation de la classe mère car ce qui est protected peut être accédé sans passer par les fonctions publiques de la classe mère, donc à moins que tu ne le veuilles expressément pour des raisons louables, c'est à éviter.

[poukill]

Tu veux dire, si je redéfinie des méthodes dans la classe fille c'est ça?
Normalement, la classe fille appelle une méthode de la classe mère... ou alors je comprend plus rien à la programmation ?

[Matthieu Brucher]

Par exemple, la classe mère a des fonctions protected qui sont appelées dans un ordre avec des préconditions et des postconditions.
Si tu hérites de cette classe, tu pourrais accéder à ces fonctions directement, ce qui n'est pas forcément judicieux si tu ne sais pas les préconditions et les postconditions.
Ou pire, tu le sais et tu programmes bien, mais qqn va hériter de TA classe de la même manière et mettre le souc partout...

[poukill]

Sur la base, je vais partir d'un schéma comme celui de la pièce jointe.

J'ai donc mis une instance de CFP (composant face au plasma) dans choc (jargon d'une expérience).
De CFP, je fais hériter deux classes : Antenne et LPT qui sont deux types d'objet face au plasma.

Ca me parait pas mal, non?

Je suis en train de me pencher sur l'implémentation des méthodes pour ne pas faire d'erreur...

EDIT : Le fait de mettre en private CFP est - il souhaitable?
Schéma mis à jour plus loin!

[Matthieu Brucher]

Ca l'air d'être un bon début