According to naming conventions I think, that pure interface classes
should start with I (e.g. IGDALRasterDataset, IGDALVectorDataset).
For the Abstract class maybe such naming will sute:
GDALEmptyRasterDataset -> GDALRasterDataset
GDALAbstractRasterDataset -> GDALRasterDatasetBase
GDALIRasterDataset -> IGDALRasterDataset
Best regards,
Dmitry
25.03.2014 16:13, Vincent Mora пишет:
On 25/03/2014 11:44, Even Rouault wrote:
Selon Vincent Mora <[email protected]>:
On 24/03/2014 21:46, Even Rouault wrote:
Hi,
"Release soon, release early", so for people who like UML diagrams
(there
is
also a prototype of C++ classes for those who don't like UML very
much),
here's
a blog entry with the outcome of my thoughts for a possible
re-organisation
of
the GDAL/OGR class hierarchy
http://erouault.blogspot.ca/2014/03/draft-gdalogr-class-hierarchy-for-gdal.html
I don't understand the need for HandleRasterData() and
HandleVectorData().
Isn't inheriting from GDALEmptyRasterDataset or GDALEmptyVectorDataset
sufficient to convey the information that the class doesn't handle
those
kind of datasets.
A call to GetLayerCount()/GetRasterCount() from the class user is
sufficient to say "no vector/raster data here", and a dynamic _cast to
GDALEmptyVectorDataset/GDALEmptyRasterDataset is even clearer to me, so
HandleRasterData()/HandleVectorData() would be a third way to tell the
same thing.
Actually, when thinking more about this, this kind of information
should be at
the driver level, and not at the dataset level. The idea is that
there are use
cases where you want to know if a driver can handle only vector, only
raster, or
both. For example if you still want to have separate Open dialog
boxes for
raster or vector.
Also I'm not sure about the names GDALAbstract* since those are partial
implementations.
I know I'm not very good at naming. Do you have an alternative
proposal ? The
issue is that with my draft we end up with a lot of classes and
interfaces, so
it is not obvious to find a good name to reflect their content.
Partial sound ok to me, but I not so good at naming ?
Considering the number of classes, I gave it some thoughts this
morning and, like Dmitry, thought of merging the Abtract (Partial)
into the interface before realizing that, even if it works (you can
overload de default function in Empty) it's a bit ugly and I ended up
preferring your solution.
An altenative would be to have a Dataset with both aspects and provide
three partial specialisations: one for vector (it will behave like
empty raster) one for raster, and one for both. Code duplications
could be avoided by implementing protected member functions in the
Dataset class and simply calling them in the implementations of
partial specialization. This solution avoid the diamond shaped
inheritance diagram of hell :)
Even
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
