reference to an interface

[Ryan Steen]

In article <e1b1ok$2c5h$1 at digitaldaemon.com>, Søren J. Løvborg says...
>The factory method is not a requirement in the interface, unless the 
>interface represents the ability to produce objects implementing itself.

>Rather, you need a separate factory class (or interface) which provides the 
>ability to produce objects implementing I.

In either case the factory is a member of the _human_ interface to that piece of
software. In the second case the factory is by defintion not a member of the _D_
interface. And in the first case it is a member of the _D_ interface but it is
unusable because it is not instantiated.

So you have confirmed, that currently _human_ interfaces cannot be expressed by
_D_ interfaces. 


>Again, not sure what you're trying to do here.

Please follow another two trys of explanation.


First I want you to recall the semantics of the pipe symbol in sh, bash and
other shells. A pipe serves as a very simple interface between programs which
act as filters. In total the pipe allows you to decompose a complex task into
more managable subtasks.

1.
Consider the case, that you as the boss of a department have analyzed such a
complex task to be decomposable in ten subtasks to which you assign your ten
implementers one by one. You want to replace the pipe symbols by adequate
D-interfaces, which you define in a separate D-module, but your implementers
cannot instantiate them as outlined above.

2.
Consider the case that you as before are yourself assigned a subtask of a more
complex task. But your boss has left the details of the interfaces to the bosses
of the departments. Therefore you have to establish contracts with the bosses of
the tasks that are neighbours to your task in form of D-instances. You are
facing the same problem as outlined under 1. and in addition you want to
encapsulate the implementators of your department by implementing the
D-interfaces through wich they must communicate with the world outside of the
department. 

But because the boss of your neighbour task does the same there are now two
D-interfaces for that one human interface and there is no way to declare two
interfaces as aliases of each other.

In total: D-interfaces are not able to mimic human interfaces.

So what else can be used to model the cases outlined above?