[gdal-dev] Draft GDAL/OGR class hierarchy for GDAL 2.0

[Florent JITIAUX]

2014-03-27 11:24 GMT+01:00 Even Rouault <even.rouault at mines-paris.org>:

> Hi,
>
> > Hi all,
> >
> > MY opinion is that's not a really good way to count how many classes you
> > will have and trying to have minimal classes.
> >
> > Drawing a model with UML is not easy : it's not easy to have a good model
> > from the beginning, it's not easy to name all members and methods
> > correctly, and the worst is inheritance.
> > You can think you spend too much time to make the model. But you can't
> say
> > if you will spend less or much time to change code because your model was
> > too simple.
>
> The issue is that I'm trying to "refactor" a code base of 1.2 million
> lines of
> C/C++ code (not mentionning the 140 000 lines of Python tests), and with
> 211
> existing drivers. So, given that nobody will probably ever want to fund the
> effort, it is completely excluded to have to edit each of those drivers in
> a non
> automated way...
> The end solution will necessary be a compromise. I would also like the
> existing
> C API to continue working as much as possible.
>
> That was not a reproach because I know refactoring may be very difficult
and it's takes so much time. But that's why making a model which can evolve
is important.


> >
> > Because I don't know all the model of Gdal and the model can be "reset" I
> > have some questions :
> >
> > 1) Why GDALMajorObject not inherit of GDALIMajorObject ?
>
> It was just an omission in the UML diagram. My C++ sketch had this
> inheritance.
>
> >
> > 2) Why all classes inherit (directly or not) of GDALMajorObject ?
>
> That's how it is done currently.
>
> > What do
> > you store in it ?
>
> It contains a list of list of strings, or in more concrete terms, metadata
> domains that contain metadata items.
>
> > Is it possible to put it as a member in classes ?
>
> That could have been a way of doing it, yes. Always the debate composition
> vs
> inheritance.
>
> The question is : classes (Raster, Driver, ...) are a GDALMajorObject or
classes have a GDALMajorObject ? If it's just a list (map with key/value ?)
of String, I'm not sure it defines what subclasses are.

I know it's not important for a lot of people but I like when a model is
precise. At the beginning, you could only draw interfaces to define what
classes and subclasses are.


> > Have
> > you consider templates ?
>
> Actually, no. I tend to avoid them unless they are an obvious solution.
>
> >
> > 3) An interface for Drivers ? geName(), getLongName(), getDescription() ?
> > Or maybe abstract ...
> >
> > 4) What is GDALDataset in your diagram ?
>
> It is the base class that a driver that supports both raster and vector
> would
> have to subclass.
>

I think I missed something : today is there a driver which support both ?


>
> >
> > 5) Where is the link between Driver (Gdal/Ogr) and Dataset
> (Raster/Vector)
> > ? Member, templates ?
>
> A Driver instanciates a Dataset by opening an existing one, or by creating
> a new
> one. But the Dataset object itself is a free-standing objects that is only
> owned
> by user code, and not by the Driver.
>
> For now, I've dropped my crazy UML diagram that nobody would be able to
> understand, even if I managed to make it work, and I'm pursuing my attempt
> just merging OGRDataSource inside GDALDataset. And make OGRDriver and
> OGRSFDriverRegistrar mostly disappear, or just create a minimized version
> of
> them, as compatibility layer for existing drivers, that forward the real
> work to
> GDALDriver and GDALDriverManager.
>
> Your diagram is understandable. This is just because everyone has his own
representation of a model and it is important (for me) to understand why
your model is like that. With good arguments people can agrees.


> Even
>

Florent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140327/5ab7b6a9/attachment.html>