Re: Separation of API and implementation

On Tue, 14 Aug 2007 13:58:13 -0000, hforco2@xxxxxxxxxxxxxx wrote:

I have an API defined in one plugin, in a set of packages. Call this
plugin A.

Another plugin contains my implementation, in a set of different
packages. Call this plugin B.

I have interfaces X and Y in A where X is defined as follows:

interface X {
void foo(Y y);
}

Now I implement X in B as follows:

class XImpl implements X {
public void foo (Y y) {
// Do something with Y
}
}

The problem I have is the 'Do something with Y'. Y is an interface and
has been designed to be reasonably generic i.e. not specific to the
implementation B.

= bad design

IF foo's implementation depends on both Y and X THEN foo is double
dispatching. HENCE X and Y cannot be independent interfaces, because they
are coupled through common foo.

But the implementation in B only works if I assume Y is actually B's
implementation of Y, say YImpl.

So 'Do something with Y' becomes:

// Cast to my implementation:
YImpl myImpl = (YImpl) y;

This raises several questions:

Am I ok to assume the cast will work?

No, you cannot, because nothing in your design warranties that.

This is presumably quite a common problem. In cases like this, is it
accepted that you won't get more than one implementation being mixed
with another, i.e. if I get passed back an interface from A then I can
assume it is my B implementation?

This is the problem of parallel types hierarchies which represents a
specific case of general multiple dispatch. It is difficult in any
language. Sometimes delegation or generics help, sometimes not.

But often hierarchies aren't not really parallel. Either X or Y could be
designed class-wide. Then you dispatch along the opposite axis and no
second dispatch (poorly emulated by a cast in your example) is needed.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • C# Plugin system - same interface in two different assemblies...
    ... I am now aware that in C# if you reference the same interface from the same file in two different projects the types are actually incompatible. ... I found this out because I have written a generic plugin system for my current and future C# needs. ... When you compile and build both projects (we haven't even defined an interface which inherits from IPlugin yet, lol) and run the host.exe application, the host creates an instance of the plugin manager and tells it to load the dll produced by the MyPlugin project. ... This means that the runtime considers the interface IPlugin, which is of course defined in both assemblies so that each assembly can use it, to be different in each assembly. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Separation of API and implementation
    ... I have an API defined in one plugin, ... interface X { ... Think about what the primary characteristic of all plugins is: it provides services that one can plug it into various client contexts. ... IOW, it isn't a plugin if any of these things is not true. ...
    (comp.object)
  • Re: How to use interfaces properly...
    ... > MyInterfaceTest). ... > property on the reference to "false". ... > interface have to have its own copy of the dll that contains the ... > references that will work during development, but will also let the plugin ...
    (microsoft.public.dotnet.framework)
  • Re: [linux-pm] Power Management framework proposal
    ... the software needs to know what the interconnects and dependancies ... > so that one can make a plugin specific for each device. ... > i believe there is no way to do an abstract interface for this and trying to ... there power management tunning capacity, Then an ohm plugin would use ...
    (Linux-Kernel)
  • Re: Separation of API and implementation
    ... I'm missing something or an Abstract Factory could help? ... I have an API defined in one plugin, ... interface X { ... implementation of Y, say YImpl. ...
    (comp.object)