[Dcmlib] Classes PixelReadConvertor etc
Mathieu Malaterre
mathieu.malaterre at kitware.com
Thu Feb 3 16:48:09 CET 2005
Jean-Pierre Roux wrote:
> Bonjour.
>
> En ecrivant des exemples 'pegagogiques' d'utilisation de gdcm, je me
> disais que si, au niveau utilisateur, qui que ce soit utilise une de leurs
> methodes pour faire quoi que soit, il est assure de ne pas aller loin ...
>
> Les methodes contenues dans ces classes n'ont de sens *que* si elles sont
> appellees en interne, par FileHelper.
> PixelReadConvertor etc sont des classes 'de service' par FileHelper, et ne
> devraient pas etre visibles a l'exterieur de FileHelper.
C'est la raison pour laquelle toutes les realtions etaient garantie par
des firned. Et c'etait a mon avis la bonne apparoche.
> En l'abscence de la notion d'Embedded Class, en C++, la manip de
> serait-elle pas de mettre *toutes* les methodes de PixelReadConvertor
> (constructeurs, destructeur, accesseurs) en private et de declarer
> FileHelper 'friend' de PixelReadConvertor.
>
> (Benoit n'aime pas les friends lorsqu'elles ont ete mises juste our eviter
> d'ecrire un accesseur sur un champ d'une classe, mais la, le cas est
> different ...)
Ben encore une fois tu fais peter ton API public, tu augmentes ta doc
doxygen et tu augementes les risque qu'un utilisateur essai d'y acceder.
> Bon ...
> La vraie solution serait de *supprimer* ces classes et de tout(re)mettre
> dans FileHelper, mais c'est plus long a faire.
Non ! PixelReadConvert ressemble de loin a ce que veux: une super classe
decompressor. Ensuite FileHelper aura un Decompressor ( JPEG, RLE, RAW
). FileHelper ne fais que lire les donnees et le
Decompressor/PixelReadConvertor transforme les donnees.
Mathieu
More information about the Dcmlib
mailing list