[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