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/

[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]

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

[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

[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]

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]

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]

Pour un composant, est-ce que tu peux avoir plusieurs expériences ? Est-ce qu'une expérience se rapporte à un seul composant ?

[poukill]

Pour un composant, est-ce que tu peux avoir plusieurs expériences ? Est-ce qu'une expérience se rapporte à un seul composant ?

C'est pas facile à répondre Miles

Je t'explique où j'en suis !
J'ai la classe CFP (Composant Face au Plasma), et deux classes qui en dérivent : Antenne et LPT (je passe les détails ! )
Les composants sont toujours les mêmes, on les connait bien (ils sont très gros, et on peut pas les bouger !!!!)

Par contre, la donnée de base, c'est le numéro de l'expérience. C'est à dire qu'on lance l'analyse que si on a le numéro de l'expérience... En gros, on analyse qu'une seule expérience à la fois si tu veux...

Ma classe Experience, qui possède la variable num_experience, je la mettrais donc comme instance dans la classe CFP !

Comment vois-tu ça? Du bon oeil?

MERCI

[Swoög]

personnellement, j'aurais plutôt tendance à mettre une instance de Composant dans Expérience...

parce que l'Expérience utilise le Composant...

Si tu préfère le Composant est une partie de l'Expérience, une donnée (dans le cas présent c'est plutôt un générateur de données)

L'Expérience aura besoin d'utiliser le Composant en interne, pas l'inverse

[Matthieu Brucher]

Si pour un composant, tu as plusieurs expériences possibles, je serai d'avis de ne pas mettre le n° de l'expérience dans la classe du composant.
Si tu dis que tu analyses une expérience à la fois, pourquoi avoir besoin de stocker le n° de l'expérience ?
Si tu en as besoin pour des questions de résultats, je verrais plutôt alors une classe globale qui contient un pointeur vers un composant et qui est responsable de la génération du rapport, par exemple.

[Matthieu Brucher]

personnellement, j'aurais plutôt tendance à mettre une instance de Composant dans Expérience...

parce que l'Expérience utilise le Composant...

Si tu préfère le Composant est une partie de l'Expérience, une donnée (dans le cas présent c'est plutôt un générateur de données)

L'Expérience aura besoin d'utiliser le Composant en interne, pas l'inverse

+1

[poukill]

C'est vrai...
Je me suis juste dit que le numéro d'expérience, c'est pas le plus important. Enfin, je veux dire que les méthodes seront dans la classe CFP!
Etant donné que la classe Expérience ne possède qu'une seule variable...

Une autre question que je me pose: dois-je déclarer CFP comme classe virtuelle??? Quelles sont les conséquences (je viens du C et du java!!!!)?
Faudra t-il recoder toutes les méthodes dans les classes filles comme en java?

Merci bcp Swoög et Miles

[poukill]

Si tu dis que tu analyses une expérience à la fois, pourquoi avoir besoin de stocker le n° de l'expérience ?

En fait, j'en ai besoin, car le numéro de l'expérience me permet d'aller chercher des paramètres sur le serveur central... C'est très important

Si tu en as besoin pour des questions de résultats, je verrais plutôt alors une classe globale qui contient un pointeur vers un composant et qui est responsable de la génération du rapport, par exemple.

Hum... oui, il faut que j'y réfléchisse !

Pour ce qui est du numéro d'expérience, c'est vrai que le comportement général, c'est quand même celui-ci:
On regarde le comportement d'un composant dans une expérience donnée... Mais on peut soit être très intéressé par le comportement d'un composant au cours des dis dernières expériences, soit par le comportement de tous les composants au cours de la même expérience....

J'ai un peu du mal à choisir si vous voulez là

[Matthieu Brucher]

C'est vrai...
Je me suis juste dit que le numéro d'expérience, c'est pas le plus important. Enfin, je veux dire que les méthodes seront dans la classe CFP!
Etant donné que la classe Expérience ne possède qu'une seule variable...

Une autre question que je me pose: dois-je déclarer CFP comme classe virtuelle??? Quelles sont les conséquences (je viens du C et du java!!!!)?
Faudra t-il recoder toutes les méthodes dans les classes filles comme en java?

Merci bcp Swoög et Miles

Beurk, si tu fais ça, bon courage quand tu voudras ajouter des extensions.
CFP étant la classe globale, elle contient des méthodes virtuelles pures par lesquelles tu obtiendras les éléments nécessaires auprès de chaque composant. Un héritage, ça sert à ça, ça évite de devoir à chaque fois caster vers une sous-classe de CFP.