[Kstars-devel] SkyPoint/SkyObject refactoring

[Khudyakov Alexey]

On Thursday 28 of May 2009 16:22:47 Akarsh Simha wrote:
> > I think that SkyPoint class should not be superclass of SkyObject.
> > Instead it should be its data member.
> >
> > It could be justified by following arguments. SkyObject  _is_  _not_
> > really a SkyPoint it is a some entity which has some celestial
> > coordinate.  Moreover SkyPoint doesn't define any virtual methods except
> > for updateCoords and so doesn't define any part of SkyObject's API. And
> > last point is SkyPoint is used on its own without regard to SkyObject
> > family.
> >
> > Cons: This is and extensive change.
> >
> > Any comment/suggestions/whatever ?
>
> I don't see why (from KStars' point of view) a SkyObject is not a
> SkyPoint (with some dimensions and extra attributes). I wonder if it
> is worth all the effort to tackle this. SkyObject is comfortably
> extending SkyPoint, right?
>
SkyObject is not SkyPoint because it's impossible to replace S.O. with S.P. 
unless all you need is coordinates. 


> Moreover, the code will become much more complicated if a SkyObject
> has a SkyPoint rather than inheriting from it. We will need to call
> SkyObject::point()->ra() for instance, or reimplement a host of
> functions. I don't think the change is worth the effort.
>
I could tell whether change will be for worse or better. This could be 
determined only experimentally. So I'll try write patchset which implement 
such change. It should be useful anyway since it will provide knowledge on how 
should things be done. 

My main complaint about kstars design is that it's tight coupled and not 
orthgonal. When I want to look at one thing I have to look at many.
I don't know how this could be improved so I'm trying to do something and look 
for result. 

--
  Khudyakov Alexey