(Started this page ... first thoughts, multiple possibilities) |
|||
| Line 6: | Line 6: | ||
To find out which is the wisest I try to look at every single class: | To find out which is the wisest I try to look at every single class: | ||
| + | |||
| + | === Base data === | ||
| + | * '''GeoDataCoordinates''' This one is quite simple. It is not more than a QPoint in GeoCoordinates. This should stay implicilty shared. | ||
| + | * '''GeoDataLatLonBox''' (GeoDataObject) It seems to nothing more than a QRect for GeoCoordinates. I'm not sure if it must be derived from GeoDataObject | ||
| + | ** '''GeoDataLatLonAltBox''' same for this | ||
| + | |||
| + | === Geometric structures === | ||
| + | * '''GeoDataGeometry''' The base class for all geometric. We could want a pointer for this, so using it as data may not be the right way. | ||
| + | ** '''GeoDataPoint''' This one uses multiple inheritance (GeoDataCoordinates). I don't think that this is semantically correct. | ||
| + | |||
| + | === views === | ||
| + | * '''GeoDataAbstractView''' It's nothing more than a view, this could stay implicitly shared. | ||
| + | ** '''GeoDataLookAt''' Same for this as this is a child. | ||
Implicit sharing and storing objects as value is very reasonable for basic data as QStrings, but there are reasonable doubts regarding Placemarks and other GeoData. There are some possibilities:
To find out which is the wisest I try to look at every single class:
KDE TechBase 