Difference between revisions of "Refactoring of the Geometry Classes"

From mitk.org
Jump to navigation Jump to search
(First part of guidline)
(Added Images with class strucuture)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
 
= Migration Guide for [[TimeSlicedGeometry]] to [[TimeGeometry]] =
 
= Migration Guide for [[TimeSlicedGeometry]] to [[TimeGeometry]] =
Our geometry-concept has been changed to simplify the use of the geometry. As a first step the [[TimeSlicedGeometry]] has been removed. By now, all time information will be stored in a new class named [[TimeGeometry]].  
+
Our geometry-concept has been changed to simplify the use of the geometry. As a first step the [[TimeSlicedGeometry]] has been removed. By now, all time information will be stored in a new class named [[TimeGeometry]].
  
The old structure is displayed in the image below. The geometry of each [[BaseData]]-object, for example an image, has been represented by a Geometry3D-Class. Usually this was not an Geometry3D but an derivated class mostly an [[TimeSlicedGeometry]].  The [[TimeSlicedGeometry]] was responsible for managing the geometry for different time points but also provided functions like transformation etc.  
+
The old structure is displayed in the image below. The geometry of each [[BaseData]]-object, for example an image, has been represented by a Geometry3D-Class. Usually this was not an Geometry3D but an derivated class mostly an [[TimeSlicedGeometry]].  The [[TimeSlicedGeometry]] was responsible for managing the geometry for different time points but also provided functions like transformation etc.
  
The geometry-concept has been redesigned.  The new structure is shown in a simplified class diagram below. Now [[BaseData]] holds a [[TimeGeometry]] which is basically a container for different Geometry3D-Objects for each time point. Since [[TimeGeometry]] is just an abstract class the data management is mainly done in a subclass. This is done to be able to support different scenarios.  The biggest change introduced by this new concept is that [[TimeGeometry]] does not inherit from Geometry3D. Therefore a cast to Geometry3D is no longer possible. Also [[TimeGeometry]] itself does not provide any transformation information. To get the transformation for a [[BaseData]]-Object a time point must be specified and the corresponding Geometry3D will contain the transformation.
+
[[Media:Development$$Refactoring_of_the_Geometry_Classes_-_Part_1$geometry_old-structure.png|Media:Development$$Refactoring_of_the_Geometry_Classes_-_Part_1$geometry_old-structure.png|show|larger version|width="750"]]
 +
 
 +
The geometry-concept has been redesigned.  The new structure is shown in a simplified class diagram below. Now [[BaseData]] holds a [[TimeGeometry]] which is basically a container for different Geometry3D-Objects for each time point. Since [[TimeGeometry]] is just an abstract class the data management is mainly done in a subclass. This is done to be able to support different scenarios.  The biggest change introduced by this new concept is that [[TimeGeometry]] does not inherit from Geometry3D. Therefore a cast to Geometry3D is no longer possible. Also [[TimeGeometry]] itself does not provide any transformation information. To get the transformation for a [[BaseData]]-Object a time point must be specified and the corresponding Geometry3D will contain the transformation.
 +
 
 +
[[Media:Development$$Refactoring_of_the_Geometry_Classes_-_Part_1$geometry_new-structure.png|Media:Development$$Refactoring_of_the_Geometry_Classes_-_Part_1$geometry_new-structure.png|show|larger version|width="750"]]
  
 
Most changes introduced by this redesign of the geometry affect the handling of the [[BaseData]] and any class that is derived by it. The next sections will explain how the most important functions which changed can be replaced.
 
Most changes introduced by this redesign of the geometry affect the handling of the [[BaseData]] and any class that is derived by it. The next sections will explain how the most important functions which changed can be replaced.

Revision as of 10:57, 3 September 2013

Migration Guide for TimeSlicedGeometry to TimeGeometry

Our geometry-concept has been changed to simplify the use of the geometry. As a first step the TimeSlicedGeometry has been removed. By now, all time information will be stored in a new class named TimeGeometry.

The old structure is displayed in the image below. The geometry of each BaseData-object, for example an image, has been represented by a Geometry3D-Class. Usually this was not an Geometry3D but an derivated class mostly an TimeSlicedGeometry. The TimeSlicedGeometry was responsible for managing the geometry for different time points but also provided functions like transformation etc.

Media:Development$$Refactoring_of_the_Geometry_Classes_-_Part_1$geometry_old-structure.png|show|larger version|width="750"

The geometry-concept has been redesigned. The new structure is shown in a simplified class diagram below. Now BaseData holds a TimeGeometry which is basically a container for different Geometry3D-Objects for each time point. Since TimeGeometry is just an abstract class the data management is mainly done in a subclass. This is done to be able to support different scenarios. The biggest change introduced by this new concept is that TimeGeometry does not inherit from Geometry3D. Therefore a cast to Geometry3D is no longer possible. Also TimeGeometry itself does not provide any transformation information. To get the transformation for a BaseData-Object a time point must be specified and the corresponding Geometry3D will contain the transformation.

Media:Development$$Refactoring_of_the_Geometry_Classes_-_Part_1$geometry_new-structure.png|show|larger version|width="750"

Most changes introduced by this redesign of the geometry affect the handling of the BaseData and any class that is derived by it. The next sections will explain how the most important functions which changed can be replaced.