reference to an interface

[Søren J. Løvborg]

Ryan Steen wrote:
> As I understand it now, an interface is a requirement and a promise; it
> establishes a contract between three parties: client --- serverBoss ---
> implementer.

Not sure what you mean. An interface represents an ability, or 
functionality. For instance, take the interface std.stream.InputStream, 
which represent the ability to deliver bytes from an unspecified source.

A class implementing an interface promises to provide this functionality. 
That's only two parties: the implementing class (implementer?) and the 
program using it (boss?).

> But if so, then the interface opens only a view to the class fulfilling 
> the
> promise. The class itself, which may fulfill also the promises of other
> interfaces, is of no interest and should be kept private.

Yes, you can either make the implementing class public, and allow the user 
to construct it, or use a factory method that constructs the object for the 
user, hiding the implementing class.

> But if it is private one cannot instantiate it and one needs a function
> "resolve". But this function cannot be private and therefore is not 
> allowed to
> belong to the interface.

The factory method cannot possibly belong to the interface, since you don't 
have an instance of the interface until the method returns.

> But it is a requirement and should go into an interface ....

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.

> What I mean is, that when I am a client, then I want to code
(...)
> serverboss.I i;
> implementer1.resolve( i);

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

-- 
Søren J. Løvborg
web at kwi.dk