Re: [gobo-eiffel-develop] bridge pattern and feature comments

[Berend de B. <be...@po...>]

Andreas Leitner <no...@sb...> writes:

> The brige pattern introduces for almost all interfaces 2 + n classes
> (one class for the user interface, one class for the implementation
> interface and one class for each implementation). The classes
> usually are very very similar, meaning that feature comments are
> mostly identical as well.

And especially if you start to introduce things like my validating
parser that has to work with any implementation and seems to need two
sides: implementation and interface.


> If the kernel io approach is indeed better, I am not sure if we
> should convert GOBO XML. If the amount of work neccessary to be done
> is worth it. IMO GOBO would look a bit more homogenous if GOBO XML
> would not use the bridge pattern.

Important things, IMO, to take into account are:

1. Do we want to switch, on the fly, in the same program, between
   different XML parsers? My answer would be NO (at least not out of
   the box, there are work-arounds of course).
   If no, this means particular parsers can live in different directories,
   have the *same* name, and by choosing a particular directory you
   are working with that parser.

2. Do we want to have the ability to inherit from a given
   implementation? My answer would be YES.

3. Do we want layers, i.e. have a validating parser using any
   particular implementation? YES of course. The DOM generator is also
   a layer upon a parser IMO.
   But how? Having the validating parser inherit or use a parser? The
   validating parser looks like any simple non-validating parser, so
   itself either inherits from some base parser class or from the
   particular implementation.
   I favor the first approach (as it is now more or less): the
   validating parser inherits from a base parser class and uses a
   particular parser.

   Three is about the ability to move code that is common accross all
   implementations into a separate class, a layer you can insert
   before the calls finally reach the user program.

   I don't favor using a single inheritance tree. A validating parser
   can inherit from a particular implementation and this would
   work. But:
   1. the client interface depends on the particular implementation
      choosen at a time.
   2. It's easier to make the fault of writing something that depends
      on a particular implementation, instead of being
      portable. Because you inherit from a particular implementation, you
      have features you in other situations don't have.
   3. A validating parser isn't a particular implementation nor
      dependent on it. So this modeling is wrong.

4. Another thing I would like is to have several base layers:
   a. A very simple layer only having start/stop tag and data.
   b. The full-blown expat thing.

   This way it's easier for people to make a particular implementation
   and it's easier to check at compile that an implementation doesn't
   have implemented everything.

From this requirements it seems the current approach isn't too bad. It
can do these things (almost). In particular, I don't see how we can do
3 without agents. If we can decide to use agents, a different design
can be done.

-- 
Groetjes,

Berend. (-: