Design help...an explosion of interfaces......

From: Mark Nicholls (Nicholls.Mark_at_mtvne.com)
Date: 08/26/04 

Date: 26 Aug 2004 03:18:39 -0700

I have a set of class libraries that implement a pipe, pipereader,
pipewriter model.

unfortunately the nature of pipes means that even though different
pipe implementations have the same interface signatures their
behaviour is different in significant ways that require explicit
indentification....

I have roughly....

IPipe
IPipeReader
IPipeWriter
IPipeFactory
IPipeReaderFactory
IPipeWriterFactory

some pipe implementations don't (intrinsically) buffer data (you can
argue whether 'pipe' is a sensible name in these contexts) i.e. if you
write data into the pipe and noone is listening the data is lost, so
we want to make the distinction so....

IBufferedPipe : IPipe
IBufferedPipeReader : IPipeReader
IBufferedPipeWriter : IPipeWriter
IBufferedPipeFactory : IPipeFactory
IBufferedPipeReaderFactory : IPipeReaderFactory
IBufferedPipeWriterFactory : IPipeWriterFactory

The subtypes seem valid as the extra behaviour of buffering does not
contradict the behavioural (informal) contracts on the base
interfaces.

oh dear, to make the factories type safe I need to overload their
Create methods with the correct return type....it's getting
messy....i.e.

interface IPipeFactory
{
IPipe CreateNewPipe();
}

interface IBufferedPipeFactory : IPipeFactory
{
IBufferedPipe CreateNewPipe();
}

and obviously (well not so obviously to me but) my class has to
explicitly implement both;

IPipe CreateNewPipe();
IBufferedPipe CreateNewPipe();

even though they both do exactly the same thing, and you would have
thought the compiler could have realised IBufferedPipe CreateNewPipe()
is an implementation of IPipe CreateNewPipe()....but that's probably
another story....

Now I want
IPersistentBufferedPipe : IBufferedPipe
etc

now it's getting very messy.....

advice....

P.S.

And yes I do want it type safe, pipes by their nature can be connected
together and I want these connections to be valid and enforced at
compilation time.

Relevant Pages

  • Re: Design help...an explosion of interfaces......
    ... > I have a set of class libraries that implement a pipe, pipereader, ... > pipe implementations have the same interface signatures their ... > IBufferedPipeFactory: IPipeFactory ... > IBufferedPipe CreateNewPipe(); ...
    (comp.object)
  • Re: Design help...an explosion of interfaces......
    ... > pipe implementations have the same interface signatures their ... > write data into the pipe and noone is listening the data is lost, ... > IBufferedPipeFactory: IPipeFactory ... > IBufferedPipe CreateNewPipe(); ...
    (comp.object)
  • Re: Design help...an explosion of interfaces......
    ... >> Its pretty clear that some transactions between client code and Pipe ... >> IBufferedPipe CreateNewBufferedPipe() ... > Note there is no special IBufferedPipeWriter interface, ... void BufferedSampleClientCode(IBufferedPipe pipe) ...
    (comp.object)
  • Re: Design help...an explosion of interfaces......
    ... >> I'm not sure I would use an isBuffered attribute unless a Pipe was able ... >> this way implies that the attribute won't allways be the same for a ... void foo(IPipe& p) { ...
    (comp.object)
  • [RFC v16][PATCH 25/43] tee: dont return 0 when another task drains/fills a pipe
    ... This patch is a modified version of Max Kellerman patch that fixes ... do_teeensures that ipipe is readable and opipe is writable by ... - these two functions unlock the pipe after they have waited ...
    (Linux-Kernel)