[IGSTK-Developers] State machine architecture

[Tina Kapur]

Hi Andinet,

Allowing the flexibility to add future trackers is a good idea.  For
example, GE's navigation business (where I spent my "formative" years) has
its own tracker that might be good to be able to interface to down the road.
There are also some startups that want to figure out how to build
better-faster-cheaper trackers, so we'd want to be prepared for that
scenario.

My preference is pretty much always to keep base classes as minimal as
possible and save the additional features in derived classes. 

Having said all this, if the current architecture doesn't hinder progress
for the next five years, then it will have served its purpose i.e. if a
refactoring is needed after that, that's not such a bad thing...

-Tina
 

>-----Original Message-----
>From: 
>igstk-developers-bounces+tkapur=epiphanymedical.com at public.kitw
>are.com 
>[mailto:igstk-developers-bounces+tkapur=epiphanymedical.com at pub
>lic.kitware.com] On Behalf Of Andinet Enquobahrie
>Sent: Thursday, August 18, 2005 8:14 AM
>To: igstk-developers at public.kitware.com
>Subject: [IGSTK-Developers] State machine architecture
>
>Dear all,
>
>The architectural decision of  the state machines in IGSTK 
>boils down to the question of  whether to integrate the state 
>machines in the base classes or derived classes or in both ( 
>hierarchical class design). I had a chance to discuss this 
>issue with David and Luis this week.  
>Adding state machines into the base class will help to 
>streamline and enforce derived classes to use the same states 
>and transition conditions . On the other hand, adding state 
>machines into the derived classes will create a more flexible 
>and extendable architecture to integrate newly features  
>(states, transitions) in the future which might not have been 
>anticipated during the base class design.  For example, if we 
>would like to handle trackers from a different manufacturer, 
>we might be having difficulties with the current  state 
>machine design in the Tacker classes.
>
>I wll be starting to integrate state machines into the Image 
>reader classes soon.  That is why I thought we would debate on 
>it,  pick one architecture and  resolve this issue once and for all.
>
>Any thoughts?
>
>Thanks..
>
>-Andinet
>
>
>
>
>
>
>
>
>
>_______________________________________________
>IGSTK-Developers mailing list
>IGSTK-Developers at public.kitware.com
>http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>
>