[Héritage] Hériter d'une bibliothèque

A partir du moment où l'on défini un constructeur, il n'est absolument pas certain que la classe puisse être correctement initialisée sans spécifier de paramètres complémentaires. Donc on désactive le constructeur par défaut généré automatiquement. Rien n'empêche l'utilisateur d'en ajouter un s'il veut (alors que rien ne permettrai (encore) d'en enlever un).

Citation:

---

Envoyé par Miles

Ce hack est bien la preuve d'une erreur de conception bien dommageable :(

---

Ce "hack" satisfait tout de même au principe "ouvert-fermé" !
Fermé car la library peut-être utilisée tout de suite avec toute ses fonctions.
Ouverte, car d'autres fonctions peuvent être rajoutées, sans modifier l'interface de celle-ci? ;)

Qu'est ce qui te dérange là dedans?

L'interface _est_ modifiée. Avec un tel système, on peut même ajouter des variables membres, c'est du grand n'importe quoi, tout ça pour tout utiliser comme méthode. Le dernier chapitre de Exceptional C++ Style est dédié à cette horreur et la détruit purement et simplement.
Il serait tout aussi simple d'imposer ces fonctions membres comme étant libres, et on aurait EXACTEMENT la même facilité d'utilisation, en respectant cette fois-ci correctement le principe ouvert-fermé.
Le principe ouvert fermé, ce n'est pas fermé ) utilisable directement et ouvert = on peut ajouter des choses.
Fermé, c'est le fait que la bibliothèque est un tout cohérent qui n'a pas besoin d'être modifié pour ajouter une fonctionalité par exemple : là, ce n'est clairement pas le cas
Ouvert, c'est la facilité d'ajouter une fonctionalité : là, ce n'est à nouveau pas le cas puisqu'il faut modifier la bibliothèque. De plus, pour utiliser les fonctions avec un autre conteneur est impossible. Donc non, cette bibliothèque ne respecte pas, de mon point de vue, le principe ouvert-fermé, mais plutôt son contraire, le principe fermé ouvert.

ouvert = encore extensible. "Il devrait être possible d'étendre son ensemble d'opérations ou d'ajouter des champs à ses structures de données." B.Meyer
Donc on est sensé pouvoir rajouté des fonctions membres non?

fermé = accessibles à d'autres modules (interface bien définie et stable). En gros, prêt à l'emploi quoi ! :)

Citation:

---

Envoyé par Miles

De plus, pour utiliser les fonctions avec un autre conteneur est impossible

---

Ca, je veux bien te croire. Est-ce que tu pourrais me donner un exemple de ce que ça donnerait si c'était le cas? C'est pour que je comprenne le plus que je n'ai pas avec cette bibliothèque!

Citation:

---

Envoyé par poukill

ouvert = encore extensible. "Il devrait être possible d'étendre son ensemble d'opérations ou d'ajouter des champs à ses structures de données." B.Meyer
Donc on est sensé pouvoir rajouté des fonctions membres non?

---

Non, ce n'est pas exactement ça, c'est plus ouvert par héritage et autres, dont les fonctions libres. Le coeur du module n'est pas ouvert, il est fermé et donc non modifiable, toujours d'après Meyer - j'ai le bouquin chez moi ;) -

Citation:

---

Envoyé par poukill

fermé = accessibles à d'autres modules (interface bien définie et stable). En gros, prêt à l'emploi quoi ! :)

---

Et justement, avec ce truc, l'interface n'est pas stable et est différente d'un plug-in à un autre, donc non, ce n'est pas fermé.

Citation:

---

Envoyé par poukill

Ca, je veux bien te croire. Est-ce que tu pourrais me donner un exemple de ce que ça donnerait si c'était le cas? C'est pour que je comprenne le plus que je n'ai pas avec cette bibliothèque!

---

Par exemple, si les fonctions étaient du type :

Code:

---

Image::Result traitement(const Image& image)

---

aucun souci pour utiliser avec une classe fille, ou même avec tout conteneur utilisant la même interface.

Citation:

---

Envoyé par Miles

Non, ce n'est pas exactement ça, c'est plus ouvert par héritage et autres, dont les fonctions libres. Le coeur du module n'est pas ouvert, il est fermé et donc non modifiable, toujours d'après Meyer - j'ai le bouquin chez moi ;) -

---

Euh, le bouquin je l'ai devant moi :) (2 ème édition : p59) Je l'ai cité exactement!

Citation:

---

Envoyé par Miles

Et justement, avec ce truc, l'interface n'est pas stable et est différente d'un plug-in à un autre, donc non, ce n'est pas fermé.

---

C'est vrai, mais si moi j'ai écrit un plug-in, que je l'insère dans la bibliothèque, il sera valable tout le temps. Et quand je fourni mes services (ceux des classes que j'ai développées), c'est transparent pour mon client qui utilise mes classes.

Citation:

---

Envoyé par Miles

Par exemple, si les fonctions étaient du type :

Code:

---

Image::Result traitement(const Image& image)

---

aucun souci pour utiliser avec une classe fille, ou même avec tout conteneur utilisant la même interface.

---

Oui là je suis d'accord avec toi. Tu veux dire que par la manière dont la bibliothèque travaille sur les objets (sur l'instance courante en fait), ça limite la réutilisabilité.

Citation:

---

Envoyé par poukill

Euh, le bouquin je l'ai devant moi :) (2 ème édition : p59) Je l'ai cité exactement!

---

Ne lis pas que le premier paragraphe, regarde en bas de la page, les mécanismes utilisables pour faire ça ne sont pas de modifier la classe elle-même sans quoi il y a clash à plus ou moins long terme.

Citation:

---

Envoyé par poukill

C'est vrai, mais si moi j'ai écrit un plug-in, que je l'insère dans la bibliothèque, il sera valable tout le temps. Et quand je fourni mes services (ceux des classes que j'ai développées), c'est transparent pour mon client qui utilise mes classes.

---

Il ne sera valable que pour toi, dans ton contexte et ne sera pas valable pour qqs d'autre qui aura installé la bibliothèque CImg.

Citation:

---

Envoyé par poukill

Oui là je suis d'accord avec toi. Tu veux dire que par la manière dont la bibliothèque travaille sur les objets (sur l'instance courante en fait), ça limite la réutilisabilité.

---

Ca limite l'utilisabilité tout court ce mécanisme ! C'est une vraie rustine de m***e, un gros hack pour contourner le fait que la conception originale a été baclée.

Citation:

---

Envoyé par Miles

Ne lis pas que le premier paragraphe, regarde en bas de la page, les mécanismes utilisables pour faire ça ne sont pas de modifier la classe elle-même sans quoi il y a clash à plus ou moins long terme.

---

J'ai lu tout le bouquin !! ;) Oui, je suis d'accord avec toi. Celà dit, le principe ouvert-fermé reste un peu "flou" dans sa définition.

Citation:

---

Envoyé par Miles

Il ne sera valable que pour toi, dans ton contexte et ne sera pas valable pour qqs d'autre qui aura installé la bibliothèque CImg.

---

Désolé de batailler, ce n'est pas pour t'embêter, mais bien pour comprendre les mécanismes en jeu.
Non, justement. Si je crée une fichier outils.h:

Code:

---

1 2 3 4 5

#define cimg_plugin "outils.h" //va activer le plugin dans la bibliothèque #include "CImg.h"   // des fonctions membres

---

N'importe qui possédant la bibliothèque sans mes fichiers va se voir automatiquement rajouter le plug-in lorsqu'il va utiliser mes classes, non?
Si le fichier outils.h fait parti de mon "package"?

Citation:

---

Envoyé par Miles

Ca limite l'utilisabilité tout court ce mécanisme ! C'est une vraie rustine de m***e, un gros hack pour contourner le fait que la conception originale a été baclée.

---

Pour ma culture, que manque t-il, ou bien que faudrait-il changer à cette conception pour qu'elle soit correcte?

Merci Miles,

Je viens de voir que Vigra gérait la conception par contrat...
Je crois que c'est tout à fait ce qu'il me faut:

Citation:

---

vigra_precondition(PREDICATE, MESSAGE);
vigra_postcondition(PREDICATE, MESSAGE);
vigra_invariant(PREDICATE, MESSAGE);

---

Citation:

---

Envoyé par poukill

J'ai lu tout le bouquin !! ;) Oui, je suis d'accord avec toi. Celà dit, le principe ouvert-fermé reste un peu "flou" dans sa définition.

---

Non, il est très clair, sinon, dans le bouquin de Shalloway, il en est aussi question, et c'est peut-être plus précis.
Le principe ouvert-fermé indique que tu réutilises un module pour en faire un autre. Ici, tu ne réutilises pas, tu modifies, c'est très clair.

Citation:

---

Envoyé par poukill

Désolé de batailler, ce n'est pas pour t'embêter, mais bien pour comprendre les mécanismes en jeu.
Non, justement. Si je crée une fichier outils.h:

Code:

---

1 2 3 4 5

#define cimg_plugin "outils.h" //va activer le plugin dans la bibliothèque #include "CImg.h"   // des fonctions membres

---

N'importe qui possédant la bibliothèque sans mes fichiers va se voir automatiquement rajouter le plug-in lorsqu'il va utiliser mes classes, non?
Si le fichier outils.h fait parti de mon "package"?

---

Peut-être, mais qui te dit qu'il y aura compatibilité binaire avec une autre bibliothèque compilée de CImg - admettons qu'il y ait une telle bibliothèque, ce qui est possible même si CImg est template, dans le cas d'un algo spécifique - lorsque tu voudras lui donner une de tes images ?

Citation:

---

Envoyé par poukill

Pour ma culture, que manque t-il, ou bien que faudrait-il changer à cette conception pour qu'elle soit correcte?

Merci Miles,

---

- Supprimer cette possibilité de plug-in
- Arrêter de vouloir tout avoir en fonction membre, surtout si les fonctions membres sont des traitements
Meyer a une approche très pragmatique de ces choses (simplification volontaire de ma part en 2 catégories, il y en a 3, je crois) :
- si la fonction a besoin d'accéder à des infos internes à la classe -> méthode
- si la fonction n'a pas besoin -> fonction externe.
Ca simplifie le design et ça autorise beaucoup plus de réutilisabilité - ça limite aussi le nombre de méthode d'une classe à redéfinir si on veut remplacer une classe par une autre dans une bibliothèque, si l'interface est réduite au minimum... -

Citation:

---

Envoyé par Miles

- Supprimer cette possibilité de plug-in
- Arrêter de vouloir tout avoir en fonction membre, surtout si les fonctions membres sont des traitements
Meyer a une approche très pragmatique de ces choses (simplification volontaire de ma part en 2 catégories, il y en a 3, je crois) :
- si la fonction a besoin d'accéder à des infos internes à la classe -> méthode
- si la fonction n'a pas besoin -> fonction externe.
Ca simplifie le design et ça autorise beaucoup plus de réutilisabilité - ça limite aussi le nombre de méthode d'une classe à redéfinir si on veut remplacer une classe par une autre dans une bibliothèque, si l'interface est réduite au minimum... -

---

1) Quand tu parles de fontions externes, c'est fonctions libres et/ou fonctions membres d'une AUTRE classe qui traite un cas précis de calcul?

2) Sur le site de Vigra : "It's a novel computer vision library that puts its main emphasize on customizable algorithms and data structures."
Ce que ne fait pas CImg c'est bien ça?

1) Oui, c'est ça, on s'affranchit complètement de la structure à traiter à partir du moment où elle fournit une certaine interface, c'est exactement le pb que tu as toi.
2) C'est ça, puisqu'on ne peut traiter qu'un seul type de données. Dans Vigra, il existe une classe mère qui est une vue de tout et de n'importe quoi, il suffit de l'utiliser et de faire ce qu'on veut.

OK Merci Miles ! ;)
Bon week-end.