2014-03-27 11:24 GMT+01:00 Even Rouault <even.roua...@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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
