Interfaces and Constructors

[Guest]

Okay, so I know this will come off as a stupid question...but I am going to
ask it anyways...

I know you are not allowed to have constructors defined in an interface, but
why not?

I really dont need ways/design patterns around this issue. What I want to
know is why the CLR does not allow this.

Regards,
Adam

 

[Mattias Sjögren]

Adam,

I know you are not allowed to have constructors defined in an interface, but
why not?

How would you use it if it was possible? Interfaces themself can't be
instantiated and they can't have any implementation anyway. Having
constructors in an interface to enforce implementing classes to
provide such constructors doesn't make much sense either, since you
have to specify a concrete class when creating an object.


Mattias

 

[Guest]

Directly from MSDN:
"Interfaces describe a group of related behaviors that can belong to any
class or struct."

An interface is just a way to describe a contract by which a class will
implement given functionality. A constructor is the primary way to manage
all your behavior using initialization.

I am not looking to instantiate an interface, I am looking to guarantee a
class will implement a specific signature for a constructor.

public interface IBusinessObject<VO> where VO : IValueObject
{
constr(VO valueObject)
}

And an added benefit of interfaces, is that they are a great way to
establish development standards. Once again why not?

 

[Brian Gideon]

Adam,

The reason why interfaces don't define constructors is because they're
suppose to be type agnostic. But, to create and initialize an object
you *have* to know its type. However, you can abstract that away from
where it's used by taking advantage of one of the factory design
patterns. So if you want to guarentee that an IBusinessObject is
created in some special way then use a factory...say
IBusinessObjectFactory which has a parameterized Create method.

Brian

 

[Joanna Carter [TeamB]]

"Adam" <[email protected]> a écrit dans le message de (e-mail address removed)...

| I know you are not allowed to have constructors defined in an interface,
but
| why not?

This is not just a restriction in the CLR, other non-.NET languages also
don't allow this. Thinking it through, a constructor is invoked on a type,
not an instance, and it is important that this distinction is made.

Not only can you not define constructors in an interface, you cannot define
static methods either. This is for the same reason that they are not members
of an implementing object, they are members of the *type* of that object.

It may be helpful to think of this as being two classes: one for the type
and another for the instance. Delphi has the concept of a class reference,
which is essentially a "static" class, but upon which, you can call, not
only constructors and static methods, but virtual constructors and static
methods.

If you realise that constructors and static methods belong on a "reference"
class, then you can emulate the Delphi behaviour of allowing virtual
constructors and static methods by creating your own reference or metaclass.
Then, you also have the possibility of implementing an interface on the
metaclass.

Rough example :

public interface IMyInterface
{
MyClass Create();
}

public class MyClass
{
public class Reference : IMyInterface
{
public MyClass Create()
{
return new MyClass();
}

private MyClass() { }
}

public static Reference Ref
{
get { return new Reference(); }
}
}

void Test()
{
IMyInterface ref = MyClass.Ref;

MyClass cls = ref.Create();

...
}

Joanna