Discussion :

[JolyLoic]

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

[poukill]

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?

[Matthieu Brucher]

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.

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

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

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!

[Matthieu Brucher]

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 -

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

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 :

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

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.

[poukill]

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!

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.

Par exemple, si les fonctions étaient du type :

Code :

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

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

[Matthieu Brucher]

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.

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.

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.

[poukill]

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.

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 :

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

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"?

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,

[poukill]

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

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

[Matthieu Brucher]

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.

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 :

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

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 ?

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

[poukill]

- 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?

[Matthieu Brucher]

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.

[poukill]

OK Merci Miles !
Bon week-end.