[Insight-developers] Module dependcies help

[M Stauffer (V)]

Thanks Brad,

I think the trouble here is straightforward. The first dependency that
comes up is in ITK-Transform. I have a new TransformParameters class in
our RegistrationRefactoring module, and we're using it now in
TrasformBase. So ITK-Transform depends on ITK-RegistrationRefactoring
and vice versa, thus the trouble.

I can't move TransformParameters to ITK-Review, because that now throws
an error as a bad dependency if I include it as a dependency in
ITK-Transform. 

Is the new paradigm to include new classes directly in the module to
which they most directly belong, forgoing the Review module? There are
some classes in Review, e.g. CompositeTransform,  that
ITK-RegistrationRefactoring depends on, so we'll have to also move those
to other modules?

Cheers,
Michael 

>-----Original Message-----
>From: Brad King [mailto:brad.king at kitware.com] 
>Sent: Tuesday, June 14, 2011 8:56 AM
>To: M Stauffer (V)
>Cc: ITK-dev-list-mstauff at ver
>Subject: Re: [Insight-developers] Module dependcies help
>
>On 06/13/2011 12:56 PM, M Stauffer (V) wrote:
>> But there are other modules that use headers from
>> ITK-RegistrationRefatoring, and if I include 
>ITK-RegistrationRefatoring
>> as a dependency in them in order to get to the 
>RegistrationRefactoring
>> headers, it goes circular. 
>
>That probably means we have an implicit circular dependency 
>among modules
>that has just not been declared explicitly.  Can you cite an 
>example of one
>of these "other modules"?  Typically the solution is to either 
>divide the
>modules into smaller pieces to split the cycle, or to refactor the code
>to break the dependencies leading to the cycle.
>
>For example, the IO-Base module has ImageFileReader which gets reader
>implementations from other IO-* modules that themselves depend 
>on IO-Base.
>Back when they were all in a monolithic IO kit the 
>ImageFileReader actually
>included headers from all supported readers.  During 
>modularization the code
>was refactored to use a factory with runtime registration so that
>ImageFileReader does not need to include the headers of all 
>supported readers.
>This actually produced a better design because the reader does 
>not force
>a dependency on all the third-party code needed to support 
>every format.
>
>-Brad