Partage de méthodes entre deux classe sans lien de parenté?

Bonjour,

J'ai une question toute bête :
J'ai deux classes totalement indépendantes mais qui doivent utiliser la même méthode. Or ces deux classes n'ont pas de mère en commun..

Comment faire pour ne pas avoir a reécrire deux fois la méthodes..

Thanks

Créer une 3eme classe qui implémente cette méthode
Faire dériver ces 2 classes de cette classe de base

Merci

En fait j'y avait dèja penser mais bon faire une classe pour une seule fonction. Je voulas en fait savoir si il y avait pas d'autre manière.MAis c'est ce que je ferai s'il y a vraiment rien d'autre..

Encore merki

Citation:

---

Envoyé par kuja2053

En fait j'y avait dèja penser mais bon faire une classe pour une seule fonction.

---

C'est moins pire que dupliquer du code ...

C'est quoi cette méthode que tu veux utiliser ? Une méthode de classe ou pas ?

C'est censé représenter quoi ta conception?

Cette fonction doit elle accéder à des données membres ?
En fait, donne nous plus de détails sur ton contexte.

Comme dit Davidbrcz, il nous faudrait plus de détails, sinon l'héritage est pas forcement la meilleur solution, tu peux très bien faire une structure dans un autre fichier et mettre la methode en static.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

// Fichier Tools.h struct Tools { static void foo(); };   // Fichier A.h class A { void m1() { Tools::foo(); } };   // Fichier B.h class B { void m2() { Tools::foo(); } };

---

(bien sur je te laisse faire les includes).

Citation:

---

Envoyé par ram_0000

Créer une 3eme classe qui implémente cette méthode
Faire dériver ces 2 classes de cette classe de base

---

Pas dériver. Composer. Sinon on ne respecte pas le principe de substitution de Liskov, ce qui peut entrainer un non respect du principe ouvert/fermé, ce qui est le signe d'une architecture qui, un jour ou l'autre, sombrera dans le chaos. L'héritage est réservé à la définition de sous-types, c'est à dire de types dont le comportement est identique de l'extérieur à celui du type parent. L'héritage de circonstance ne rentre pas dans cette catégorie.

Citation:

---

Envoyé par leirbag

Code:

---

1 2 3 4 5

// Fichier Tools.h struct Tools { static void foo(); };

---

---

Ca, c'est du java.NET :)

Code:

---

1 2 3 4

namespace tools { void foo(); }

---

Ca, c'est du C++ :mouarf:

eheh sympa ta méthode :)
Par contre c'est pas du Java.NET la mienne :) (en plus j'en ai jamais fait :D), c'est une technique de levelisation que j'ai lu dans "Large Scale C++ : Software Design". Finalement les deux méthodes se rapproche assez, le but étant de mettre la méthode dans un endroit ou les 2 class peuvent acceder sans qu'il y ai une relation entre ces 2 class.

oula beaucoup de réponses...merci à tous...

en fait c'est une méthode qui enlève les espaces avant et après dans un string car il y a de la saisie dans mon programme. Or j'en est besoin dans deux classes qui non aucune parenté. mais bon utiliser une "mini-classe" mère juste pour une fonction, je trouve ça un peu excessif. Surtout que la fonction, grâce à la classe <string> est assez courte à écrire. J'aurais put aussi dérivé cette même classe <string> mais bon pour ajouter une seule méthode!

L'alternative avec les structures de "leirbag" et "Emmanuel Deloget"est une bonne solution pour éviter le copiage de code!!

Donc c'est ce que je vais faire, je pense...;)

Oui, dans ce cas, un namespace Tools est la bonne solution.

ok sujet résolu..

Sympa le site "Why linux is better (fr)"

Citation:

---

Envoyé par leirbag

eheh sympa ta méthode :)
Par contre c'est pas du Java.NET la mienne :) (en plus j'en ai jamais fait :D), c'est une technique de levelisation que j'ai lu dans "Large Scale C++ : Software Design". Finalement les deux méthodes se rapproche assez, le but étant de mettre la méthode dans un endroit ou les 2 class peuvent acceder sans qu'il y ai une relation entre ces 2 class.

---

Tout à fait. Ceci dit, l'un crée une classe Tools, qui reçoit donc un constructeur, un constructeur par copie, un destructeur. Cette classe peut être instanciée, mais elle ne représente aucun concept, aucune abstraction. Son intérêt est donc assez minime. C'est cependant la seule manière de créer des "fonctions libres" en Java ou en C#.

L'autre définit simplement une fonction - un algorithme, en fait - qui peut être réutilisé dans d'autres modules. Cette approche est consistante avec l'approche de la librairie standard (cf <algorithm>, <functional>, etc.)