[IGSTK-Developers] PivotCallibration design and Safety Concerns

[Hui Zhang]

Hi,

I agreed with splitting them out to several different classes. The second 
one is just manually setting the transform, and maybe the user can use 
igstkTransform directly, so probably we don't really need second one. I can 
easily split them out if approved.

Regards,
James

----- Original Message ----- 
From: "Luis Ibanez" <luis.ibanez at kitware.com>
To: "IGSTK Developers" <igstk-developers at public.kitware.com>
Sent: Friday, December 09, 2005 11:42 AM
Subject: [IGSTK-Developers] PivotCallibration design and Safety Concerns


>
> Hi All,
>
> We have been looking at the code of the PivotCallibration
> prototype and there are a number of functions that raise
> safety concerns.
>
>
> From the description of the class in the Wiki:
>
> http://public.kitware.com/IGSTKWIKI/index.php/PivotCalibration_Design
>
>
> The second and third way of using the class are a violation of
> the encapsulation, because both of them offer an opportunity
> for overriding the values of a calibration transform that could
> have been computed by using the pivoting data.
>
> This class should be limited to the pivoting computation and
> should not be attempting to provide extra arbitrary flexibility
> (read risk).
>
> It will be safer to remove the second and third usage options
> from this class, and implement them on classes of their own.
>
>
> In this way we will have three (and maybe more) Calibration
> classes with names such as:
>
>
>        1) PivotCallibration
>        2) ManualCallibration
>        3) PrincipalAxisCallibration
>
>
> The ManualCallibration class will capture the functionality
> of the second usage, which is still questionable, because
> it simply let the user load an arbitrary transform....
>
> The parameters for setting this class must not be passed
> as a matrix[][] of doubles because it brings risks of:
>
>     1) Null pointers
>     2) Dangling pointers
>     3) Non allocated memory
>     4) Under allocated memory
>     5) Arbitrary casting from other pointer types
>     6) Non-orthogonal matrices
>     7) Matrices with flipping axis (left-right flips)
>
>
> If the purpose of the double matrix[][] is to pass a rigid
> transform, then the argument for the ManualCallibration
> class should be an const & igstk::Transform. This simple
> change eliminates the seven risks listed above.
>
>
> We must keep repeating the importance of considering
> *safety-by-design* over the arbitrary conveniencies of
> application developers.
>
>
>
>     Luis
>
>
>
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>
>