[Kstars-devel] RFC: Redesing of KStars

[Thomas Kabelmann]

Hi Jason,

the names component and composite are a name convention, so everybody who is 
familar with this design pattern would easiely understand this concept. But 
surely it's just names, so we can think about how to call it else.

Currently we have a concept of separating data of it's representation. Data 
are stored in SkyObject and representation is in SkyMap. I don't want to mess 
up SkyObject with drawing code etc. A SkyComponent, or whatever we will call 
it, should have the interface with init/draw/update. Subclasses of 
SkyComponent contain a pointer to it's data. This is because not all 
components need skyobjects, for example the horizon is a list of SkyPoints. 
The horizon would look like this:

class HorzionComponent : SkyComponent
{
	public:
		draw();
		update();
		init();
	private:
		List<SkyPoint> *horizon;
}

But a StarComponent would have a StarObject as data.

You're right that we have to subclass SkyComponent in the same way like the 
SkyObject hierarchy, because the component is the class which will 
init/update/draw the data.

Thomas

Am Dienstag, 2. August 2005 19:13 schrieben Sie:
> Hi Thomas,
>
> This sounds very reasonable.  It seems like "SkyComponent" will replace
> (and extend) "SkyObject".  Why not keep the name "SkyObject"?  We'll
> probably also need to subclass "SkyComponent" in the same way that
> SkyObject is subclassed for different kinds of objects (because different
> objects draw themselves differently, for example).  I'd also suggest
> renaming "SkyComposite" to "SkyObjectGroup" or something similar.  Those
> names just seem more intuitive to me.
>
> Jason