[Liblas-devel] Design/architecture questions

[Mateusz Loskot]

On 04/12/10 22:37, Michael Gerlek wrote:
>> liblas::Reader is a thin handle giving access to the actual reader 
>> operating on LAS data. It does not provide any detailed logic
>> itself, it's just a proxy object to which a specific reader
>> implementation is attached.
>> 
>> liblas::ReaderI is the actual definition reader interface and
>> behaviour. Whatever a LAS reader is supposed to do, it should be
>> outlined in ReaderI.
> 
> Hmm.  I don't have the code in front of me, but I think you're
> saying ReaderI is an interface (no code, just declarations)

ReaderI is a definition of interface. It is a code :-)
Code like this:

class ReaderI
{
...
};

is a definition, not declaration, of class ReaderI.
Now, type ReaderI can declare only pure virtual member functions,
without providing any implementation of those. Such ReaderI
is an abstract type, being equivalent to interface.

> and Reader has-a ReaderI.

Yes, liblas::Reader is composed with pointer to ReaderI
allowing to plug in various implementations of ReaderI interface.

The pimpl is an idiom specific to C++ language.
This idiom allows to implement structure called Bridge pattern.
(Pattern, unlike idioms, are agnostic to programming languages.)
There is a shade of the behavioural Strategy pattern observable. The
liblas::Reader, apart from playing structural role for the Bridge -
abstraction, states a context for pluggable strategies, it is specific
implementations of ReaderI.

This is how it has been meant since the beginning, how it has been designed.


> From the standpoint of a user of liblas, am I to carry around a
> pointer to the Reader base class?

No. You should be able to do

void foo(liblas::Reader reader)
{
   reader.AnotherCall()
}


liblas::Reader reader(...);
reader.SomeCall();
foo(reader);

etc.

> If so, what is the difference between Reader and ReaderI?
> Seems like there are two different
> hierarchies here, and I'm trying to understand why one isn't 
> sufficient.

Bridge Pattern

> Or is it that Reader and ReaderI have different
> intended users/uses?

Yes, indeed. Your questions sort of confirm the names are not
very fortunate.

> Or is it all because of the preference for the Impl model?

I didn't suggest pimpl for the sake of using pimpl.
The idea was the Birdge Pattern as a structure that can cope
with number of concrete implementations.

> As a C# 
> programmer at heart these days I don't like the idiom personally,
> but I can see how it could help in some situations for C++ systems:

In this particular context, there is no difference really.
Bridge Pattern has settled well in C# world. More over, C# does
recognise pimpl variation called, opaque pointer/reference
or private class data.

> what are the Impl advantages we're aiming at?

Bridge Pattern

> Not trying to be argumentative here, just trying to understand the
> way things are, and the way forward...  Can you state in one or two 
> sentences the purpose for each class?

I can only speak of original design idea which is as
simple as Bridge Pattern.

Reader - abstraction (potentially base for refined abstractions)
ReaderImpl (original) - implementor
v10::ReaderImpl - concrete implementor for LAS 1.0
v11::ReaderImpl - concrete implementor for LAS 1.1
VXY::ReaderImpl - ... LAS XY

Later, things have changed more or less.

> (like they teach in the books,
> if you can't explain the class in terms of a couple sentences its
> probably too complicated?)

Bridge Pattern and you get it all.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org