[Gdal-dev] GDALDataset as a Base Class

Matt Hanson mhanson at photon.com
Wed Aug 30 10:57:50 EDT 2006


I don't mind dealing with pointers.  The purpose of the GSImage and related objects is partly to simplify data access (for use by other programmers) and also to add functionality (for image processing).  GSBand adds a data access function to return chunks of read data to CImg objects (see cimg.sourceforge.net ), but also will facilitate easy artihmetic and logical operators on entire bands.
 
However I confused by the GDALRasterBand implementation, it's an abstract class due to the pure virtual IRead function.  Thus to derive from it I would need to define that function.   How does GDAL create instances of GDALRasterBand (within the GDALDataset) without first defining that function ?    I don't see the need to be able to create GSBand objects outside a Dataset though so this is really a moot point.  Encapsulating the GDALRasterBand as a data member and recreating the interface to it is a relatively small task and works for this application.  I would use inheritance but I have too many questions with regard to the GDALRasterBand class. I'm not supposed to call the GDALRasterBand ctor directly, nor it's dtor, so how does this work with a dervied class??    I would need a copy constructor to take in a GDALRasterBand object that I would presumably get with ds->GDALGetRasterBand(bandnum), but if my derived class goes out of scope then the base class dtor will be automatically called which is a no-no for GDALRasterBand.   I guess I should add then currently my GSImage contains a vector<GSBand>.    The GSImage won't directly support removing of bands (instead you would call Subset() function which would write a new file containing the subset) and I can't currently picture a scenario where an element of vector<GSBand> would be removed but I'm not deep enough in this to say that it could never happen.
 
matt

________________________________

From: gdal-dev-bounces at lists.maptools.org on behalf of Mateusz Loskot
Sent: Tue 8/29/2006 11:11 PM
To: gdal-dev at lists.maptools.org
Subject: Re: [Gdal-dev] GDALDataset as a Base Class



Matt Hanson wrote:
> Interesting, my original implementation had GDALDataset as a private
> member as you suggest.   As I spent more time thinking about it I
> thought that a derived class would be better in the long run, so I
> started looking into what was required for that.

Matt,

...I'm back from dog walk so last reply today before going to bed :-)

Please, be aware that my reply refers to a general idea/concept,
and I likely have not considered design requirements of your project.
So, it's a kind of brainstorm from my side.

I assumed that:
- you want to avoid playing with pointers if it's possible
- you want to simplify GDAL dataset to form of image (to access
its bands, and other properties)

with these points in mind, I'd use composition.
BTW, to avoid misunderstanding, I use 'composition' term
according to this explanation:
http://ootips.org/uml-hasa.html

> As it turns out
> though I had already come to the conclusion that my GSBand class
> would have to use GDALRasterBand as a private member because of
> course you can't create raster objects directly.

Similarly to discussion above, everything depends on what is the
relation between GDALRasterBand and GSBand.
What does GSBand with the GDALRasterBand do?
Is GSBand is going to be a kind of Facade Pattern
(http://en.wikipedia.org/wiki/Facade_pattern)
that will offer realization of the same concept as GDALRasterBand,
but with simplified interface (e.g. tighter subset of functions, etc.)

Another option is taht GSBand will *extend* GDALRasterBand
functionality. In this case I'd consider inheritance.

Yet another variation possible is that may be your GSBand and other GS*
classes are going to enable users to play with values and references,
instead of pointers.

Yet more another option is that may be GSBand (and other GS* classes)
are needed to be an adapter around GDAL API (Adapter Pattern -
http://en.wikipedia.org/wiki/Wrapper_pattern)
adapting it to your system interface, etc.

> I suppose at the
> very least it makes sense to have them use the same design, thus
> GDALRasterBand and GDALDataset as private members.

I just want to say, I'm speculating a bit saying "I'd use encapsulation
over inheritance" because everything depends on your objectives.

> Thanks for the explanations, it's been a tremendous help!

I'm happy to hear I'm able to help someone with something!

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net <http://mateusz.loskot.net/> 
_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev






More information about the Gdal-dev mailing list