And yet that is what DirectX and WinRT are all about.
DirectX, yes: it's a good example of an OO library with a purely
interface-based API. The only DirectX plugin architecture I can
bring to mind, though (DirectShow filters), actually uses C++
classes (such as CSource) to hide a lot of the underlying
complexity. I get the impression that wouldn't be necessary if
interface-based plugins were as simple to create as
inheritance-based ones.
Likewise, WinRT actually hides a huge amount of complexity inside
its language bindings. Inheriting from a WinRT object using only
the underlying COM interfaces involves a lot of hassle, and is a
prime example of what I'm talking about. See here:
http://www.interact-sw.co.uk/iangblog/2011/09/25/native-winrt-inheritance
Your GUI toolkit just needs to expose interfaces for the
different
types of events it is required to handle, and you give via API
calls
objects whose instances implement said interfaces.
To avoid too much code rewrite, some component systems, COM
included,
support a form of delegation where you can implement just a
part of the
interface, while delegating the remaining calls to a contained
object.
That sounds clean in theory - but so does Pimpl, and I know from
experience that Pimpl tends to make a horrible mess out of any
codebase. It doesn't help that, as far as I know, COM is
Windows-only, and D doesn't natively support the
method-defaulting system you described.
In practice, I think that proper interoperability w/r/t classes
and inheritance will tend be cleaner than coding strictly against
an interface. This can be demonstrated by choosing any base-class
derived-class pair, from any OO codebase, and attempting to
rewrite that parent-child relationship as a server-client one.
