I just read http://blog.gurock.com/articles/creating-custom-exceptions-in-dotnet/
I don't know when it is written. It says:
"Since C# unfortunately doesn’t inherit constructors of base classes, this new type only has the standard constructor with no parameters and is therefore relatively useless."
This says the same in 2010: C#: inheriting constructors
Is this still true?
EDIT: Following on from answers, I'm sure there would be a way around the default parameterless constructor. Are there other reasons for lack of constructor inheritance?
Constructors have never been inheritable in the entire lifetime of the C# language. That hasn't changed in C# 5.0: at the end of section 1.6.7.1 of the C# 5.0 spec, it still says:
Unlike other members, instance constructors are not inherited, and a class has no instance constructors other than those actually declared in the class. If no instance constructor is supplied for a class, then an empty one with no parameters is automatically provided.
So it still holds true today, and I imagine it will remain so in the foreseeable future.
You have to explicitly call the constructor of the base class, unless the base class defines a default constructor. So yes they are not inherited.
Which sometimes lead to a bunch of boiler plate code where you do nothing than pass arguments from one constructor to another
public class NegativArgument : Exception {
public NegativeArgument() : this("The number given was less than zero"){}
public NegativeArgument(string message) : this(message,null){}
public NegativeArgument(string message, Exception inner) : base:(message,inner){}
}
but what if you had an Exception type that should always have the same message? how would you solve that if the constructors were inherited? The exception class has a constructor that accepts a message so creating a new Exception type would in that case get that constructor too, not inheriting constructors makes it easy
public class NegativArgument : Exception {
public NegativeArgument() : base("The number given was less than zero"){}
}
If the base class does not have a default constructor you will have a compile error if you do not explicitly call a base class constructor.
Constructors are not inherited in C#.
If they were, then every class would have a default parameterless constructor (because all classes derive from Object and Object has a default parameterless constructor).
Many classes should only be constructed with specific values; this would be impossible to ensure if every class had a default parameterless constructor.
You should call them explicitly the constructor of the base classes. They are not inheritable.
Didn't change anything about them.
Check out : Constructors (C# Programming Guide)
From the spec §1.6.7.1:
Unlike other members, instance constructors are not inherited, and a
class has no instance constructors other than those actually declared
in the class. If no instance constructor is supplied for a class, then
an empty one with no parameters is automatically provided.
http://msdn.microsoft.com/en-us/library/ms228593.aspx
This answer is based upon the section "Constructors are not inherited" near the bottom of this entry on Jon Skeet's blog.
Summary
There are many cases in which a derived class may require information beyond that contained in the base class. Jon gives the example of the FileInfo class which requires additional information to be well-defined. Namely, that of the file for which info is to be provided
Any suggested 'fix' for this would entail overriding things in a way that prevents constructing such derived objects using the inherited constructors. However, knowingly requiring derived classes to override their base classes in a way that makes them more restrictive goes against best practice. (see: this question for Jon's discussion of the Liskov Substitution principle and the importance of being able to use derived classes wherever their base can be used.)
Additionally, from just a maintenance perspective, forcing manual override of constructors would make it difficult to reason about future behavior should the base class constructors change, and would entail having to always check, and often modify, any derived classes when new constructors are added to the base. Even a few of these would be problematic; but in cases where there are dozens or more such classes (and derived classes of those classes, etc.), maintenance and QA will quickly become a nightmare.
Related
* NOT THIS QUESTION: Calling the base constructor in C# *
I know how to call this or base to chain constructors.
Even so, occasionally I end up with a base constructor with many parameters, and a derived class which doesn't change the constructor at all. (All the derived class is doing is changing some of the implementation details of virtual methods.) When that happens I still have to define the derived constructor and pass all the params through to the base constructor.
Question: Is there any syntax sugar that says "this class doesn't declare it's own constructor, it uses an exact replica of the base constructor."
No doubt the number of params is a CodeSmell, and I should try to fix that or create a ParamObject to hold them all,but that's not the topic of the question.
There are many other ways that I could solve this problem, I'm interested in specifically whether a syntax exists to let me solve it that way.
No - constructors are not inherited, and there's no syntax to "automagically" call base constructors that have the same parameters.
The title explains it all I believe.
In C#, I am now aware that regardless, constructors in derived classes will call a base class constructor whether it is an explicit call or an implicit default constructor. My question is why? I think it's because the derived class needs to create an object of the base class but why?
I think it's because the derived class needs to create an object of the base class but why?
An instance of a derived class is an instance of the base class. If you have a rule for what must happen when you construct an Animal, and you're constructing a Giraffe, then somehow you have to execute the rule for constructing an Animal. In C# that mechanism is "call a base class constructor".
A derived class is the base class plus extra things the derived class adds.
You still need some code that initializes the base class portion so you can add your extra parts on top. The call to the base constructor is where that initialization happens.
let's say the car is your abstract class and bmw,mazda,jeep are your driven classes.
you have fields: Name , Model,..
you have constroctor: car(),car(string model)
in car class, then when compiler doing memory allocation for object need to read abstract constructor to be aware of Name, Model.
this will call the default constructor. but you can use base("z4") to force calling overridden constructor in the abstract class.
As Scott Chamberlain said the derived class is something (plus some more features).
Of course an object can have behaviors in the constructor.
Anyway if you don't need to inherit them, you should structure your code in the right way,
you should leave base constructor empty, depends on your specific needs
You can't pass this as an argument to a base constructor - see e.g., C# language specification section 10.10.1 Constructor initializers (last line on page).
I don't understand this limitation and would like to. In C#, as opposed to C++, the instance being constructed is already at its actual type and "everything works" (though of course not everything is initialized; I mean that virtual functions called in a derived class' constructor execute the derived class' methods). Base classes are allowed to call virtual methods on themselves even though the derived class' override will be executed and the derived class might not be ready for it; that's not ruled out. So what is the reason for this restriction?
(In C++ this is allowed for three reasons. First, the user or a derived class is supposed to know what he is doing. Second, the user of C++ is supposed to know what he is doing. And third, even if the user doesn't know what he is doing the C++ philosophy is to give him the rope he requires to hang himself, and then facilitate him when he ties the knot. I actually like that philosophy!)
What I'm trying to do, by the way, is construct properly initialized list members in a circularly-linked list. There's a base class Element with a field Link to point to the next element. There's a class Head which derives from Element, it'll be the distinguished sentinel for the start of the list plus have special behavior for the entire list. The constructor for Element takes the head of the list as argument, I want to write as follows to initialize elements and the head properly:
class Element {
protected Element link;
public Element(Element prior)
{
this.link = null;
prior.link = this;
}
};
class Head : Element {
public Head() : base(this) {}
};
(Before you complain that I should do this example differently my actual code is somewhat more complicated - a specialized sparse array - and I have my reasons.) I'm going to use a factory for Lists (and a factory method on Head for adding elements) to avoid this, which arguably is better design, but I'm puzzled that this other reasonable method is outlawed.
The design of C# and .NET is intended to give the base class control over its invariants. Once the base-class constructor has been completed, derived-class code, including derived-class constructors, is allowed to manipulate the base-class portion of the object in any way allowed by the base class. A derived class cannot do anything with the object under construction other than storing values to its own (derived-type) fields prior to the base-class constructor call, but a base class contract can in effect say "I'm going to call this virtual method during my constructor, and any legitimate derived class must be prepared to deal with that".
The design does pose some limitations. The worst IMHO is that there is no mechanism by which a base class can assert control of the construction process at any time after the derived-class construction code gets access to its constructor parameters.
C# evaluates field initialization expressions before chaining to the base constructor, on the theory that this will allow derived-class objects to set themselves up before the base constructor calls their virtual methods; a consequence of this is that field-initializer expressions can't do anything with the object under construction. VB.NET runs initializers after the base constructor, which allows more convenient access but means fields will be unitialized if the base constructor calls any virtual methods. Personally, I would regard the C# approach as "almost" useful, but the inability to handle classes whose invariants would be affected by constructor parameters severely limits its usefulness.
What I'd really like to see, btw, would be for Object to include a virtual method that will run between the time the most derived constructor finishes execution or throws an exception and the time control returns to the code that calls foo = new Bar();. The primary reason that base-class constructors expose the objects under construction before derived-class constructors get to run is that there is no standard way for them to ensure that they'll ever get control after that. Such a design would greatly improve constructor sequencing. I'm not holding my breath for such a thing, though.
In C#, is there way to enforce that a class MUST have a parameterless constructor?
If you're talking about generic constraints, yes:
class SomeContainer<T> where T : new() {
...
}
If you're talking about inheritance. It is not possible to require that every class that implements your interface or inherits your base class has a parameterless constructor.
The best you can do is use reflection in your base constructor to throw an exception (at runtime), like this:
abstract class MyBase {
protected MyBase() {
if (GetType().GetConstructor(Type.EmptyTypes) == null)
throw new InvalidProgramException();
}
}
If you're talking about a single class, yes; just put one in.
Generics can enforce this, but we aren't always using generics ;p
If you are using unit tests, you could use reflection to find all the types that meet the pattern you want to have parameterless constructors (for example, everything derived from MyBaseObject, or everything in the Foo.Bar namespace), and verify that way (by finding the parameterless constructor).
If you want to assert this at runtime too (perhaps in #DEBUG), things like static constructors can be useful points to inject extra type checks.
It depends what you mean.
For example, you can constrain a generic type parameter in a class or a method to have a parameter-less constructor with the new keyword, but there's not a real method of limiting an actual class definition beyond that.
public void DoSomething<T>() where T : new() { }
As mentioned in the official MSDN documentation, the C# compiler automatically generates a parameterless constructor that initializes all member variables to default values. If you wish to enforce your own implementation, you can simply do this:
class BaseClass
{
BaseClass() { // Implementation of parameterless constructor }
}
If you're referring to generic constraints, then refer to SLaks' post.
References
http://msdn.microsoft.com/en-us/library/ace5hbzh.aspx
I've encountered a problem like this a number of times, I think there's a requirement for abstract/interface constructors. The trouble is when you're using Activator.CreateInstance or some other technique to instantiate a type which you may not implement (pretty common IoC). Life would be a whole lot easier if you could force a developer to implement a constructor with the right params - even if the purpose is just to pass the params to the base constructor.
The new() constraint has helped the problem a bit since 2.0, but it still doesn't solve the problem when using not using generics, or if you do want specific arguments (and don't want to mess about with the awkward ConstructorInfo, which can't be statically checked.)
Is there any relevance of a 'public' constructor in an abstract class?
I can not think of any possible way to use it, in that case shouldn't it be treated as error by compiler (C#, not sure if other languages allow that).
Sample Code:
internal abstract class Vehicle
{
public Vehicle()
{
}
}
The C# compiler allows this code to compile, while there is no way i can call this contructor from the outside world. It can be called from derived classes only.
So shouldn't it allow 'protected' and 'private' modifiers only.
Please comment.
There's no reason for a public constructor for an abstract class. I'd assume that the reason that the compiler doesn't complain is as simple that they just didn't spend time covering that since it really doesn't matter if it's public or protected.
Inside an abstract class, for an instance constructor, modifiers public, protected internal, and protected are all equivalent. Then internal is more strict than them, and private is the most strict access.
If all instance constructors are private, only classes nested inside the class in question can inherit from it.
Note: If no instance constructors are given for a non-static class, then the compiler will generate one by itself. That's a constructor taking zero arguments. If the class is abstract, that auto-generated constructor is protected. Otherwise it is public.
The only situation I can think of where it makes a difference if an instance constructor of an abstract class is public or protected, is when you use reflection. As an example, saying
ConstructorInfo[] ctors = typeof(Vehicle).GetConstructors();
will give an empty array if the sole constructor is protected, and a length-1 array if it's public. But of course there are overloads that specify BindingFlags, so this is not a problem, just something to remember if one uses reflection.
Dupe: there is another question on SO just like this: Abstract class constructor access modifier
The answers on that question come down to the same thing in the end: it does not really matter if you declare it protected or public.
Also there seems to be some discussion about it in literature (e.g. in Framework Design Guidelines). This is referenced in this blogpost: Good design or bad design of abstract class?
Yes, a public ctor on an abstract class is meaningless and a bit misleading as it will behave as protected in that only derived classes may call it.
A private ctor will have little meaning outside of interesting edge cases.
A protected ctor would make sense if required by derived classes.