C# constructor

[Sampat]

Hi,
I need have a base class that enforces the derived class to have a
constructor with a string parameter in it. If there is no constructor
of that type then it should ideally give me a compilation error. Is
there a way to do this.

public class Base
{
//some methods.
}

public class Derived
{
//need to have this constructor.
public Derived(string str){}
}


Thanks In Advance,
Sampat.

 

[Guest]

Is there a way to do this.

No. If you tell us why you have this requirement we may be able to suggest
an alternate solution.


Mattias

 

[Jon Skeet [C# MVP]]

I need have a base class that enforces the derived class to have a
constructor with a string parameter in it. If there is no constructor
of that type then it should ideally give me a compilation error. Is
there a way to do this.

I'm afraid there's no way of doing that.

It's fairly easy to include it in your unit tests, however.

Jon

 

[Wiebe Tijsma]

Hi,
I need have a base class that enforces the derived class to have a
constructor with a string parameter in it. If there is no constructor
of that type then it should ideally give me a compilation error. Is
there a way to do this.

public class Base
{
//some methods.
}

public class Derived
{
//need to have this constructor.
public Derived(string str){}
}


Thanks In Advance,
Sampat.

If you have a constructor in your base class that requires a string, a
derived class must pass in a string in the constructor as well.

You can't force the signature though.

Wiebe Tijsma

 

[Bjorn Abelli]

...

I need have a base class that enforces the derived
class to have a constructor with a string parameter
in it.

You can never *enforce* derived classes to that...

If there is no constructor of that type then it should
ideally give me a compilation error. Is
there a way to do this.

You don't explain why you need this, behaviour, and possibly you have
misunderstood the requirements.

Anyway, you can force the derived classes to *use* a specific constructor in
the *base* class. E.g.:

public class Base
{
private string thing = null;

// Note: The "empty" constructor is private!
private Base() { }

// The only public constructor has
// a string argument
public Base(string t)
{
this.thing = t;
}

public string Thing
{
get {return thing; }
set {thing = value; }
}
}

With that construction any derived class has to call the
"string-constructor".

public class Derived : Base
{
public Derived(string str) : base(str)
{
}
}


But you can still not force the derived class to *have* a constructor with a
string argument.

public class Derived : Base
{
public Derived() : base("Bill")
{
}
}


But perhaps this constraint is enough for your purposes...

// Bjorn A

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

No, you cannot , beside that I can't see a reason why you want to enforce
it.

The closest you can get is if Base has only one constructor with your
string as parameter, in this way you can ensure that the derived class will
call this constructor with the string, but there is nothing that prevent
something like:

public Derived():base("some string"){}

cheers,

 

[Richard Blewett [DevelopMentor]]

...


You can never *enforce* derived classes to that...


You don't explain why you need this, behaviour, and possibly you have
misunderstood the requirements.

Anyway, you can force the derived classes to *use* a specific constructor
in the *base* class. E.g.:

public class Base
{
private string thing = null;

// Note: The "empty" constructor is private!
private Base() { }

// The only public constructor has
// a string argument
public Base(string t)
{
this.thing = t;
}

public string Thing
{
get {return thing; }
set {thing = value; }
}
}

With that construction any derived class has to call the
"string-constructor".

public class Derived : Base
{
public Derived(string str) : base(str)
{
}
}


But you can still not force the derived class to *have* a constructor with
a string argument.

public class Derived : Base
{
public Derived() : base("Bill")
{
}
}


But perhaps this constraint is enough for your purposes...

// Bjorn A

Note its probably better to not put the default ctor in at all as it just
clutters the class. Once you define a ctor the compiler stops emitting a
default one for you

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

 

[Jon Skeet [C# MVP]]

No, you cannot , beside that I can't see a reason why you want to enforce
it.

I've wanted this a few times when I've been creating objects using
reflection. Consider a plug-in architecture, where the type is
instantiated by reflection. It would be nice to enforce that the type
contained the appropriate constructor signature.

Jon

 

[Bjorn Abelli]

...
[snip]

public class Base
{
private string thing = null;

// Note: The "empty" constructor is private!
private Base() { }

[snip]

Note its probably better to not put the default ctor in
at all as it just clutters the class. Once you define a
ctor the compiler stops emitting a default one for you

I put it in just as an illustration.

There could be scenarios where the developer can make use of an "empty"
constructor, and still force the derived classes to not use it directly

public class Base
{

private Base()
{
// Do something important...
}

public Base(string str) : this()
{
}


public Base(StringBuilder str) : this()
{
}

// Or whatever...
}

// Bjorn A

 

[Wiebe Tijsma]

Well, most dynamicly instantiable types use parameterless constructors...

Remoting and serialization also requires this, correct?

Also, I've always heard that it is preferable doing nothing else but
setting private fields using the c'tor parameters anywy...

2cts...

Wiebe

 

[Jon Skeet [C# MVP]]

Well, most dynamicly instantiable types use parameterless constructors...

That entirely depends on the situation, to be honest. But being able to
specify that a parameterless constructor is necessary at compile-time
would be useful.

Remoting and serialization also requires this, correct?

I think so, yes.

Also, I've always heard that it is preferable doing nothing else but
setting private fields using the c'tor parameters anywy...

Again, it entirely depends on the situation. FileStream, for instance,
certainly does more than that.

The point is that in order to get a good degree of safety when
instantiating things dynamically, it would be helpful to be able to get
compile-time safety for constructors.

Jon