This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why can’t I create an abstract constructor on an abstract C# class?
Can abstract class's Constructor be marked as 'abstract'?
No. C# does not support this in any version. Note that constructors are not inherited in derived classes, although they can be "chained". This is probably what you want to be doing.
If you want to indicate that the derived class should be doing some sort of initialisation, you could create an abstract Initialise method or such which the constructor of the base class (and indirectly of the sub-class) calls on creation.
As a side point, I'm not sure whether the CLR (or associated CIL language) actually supports it - I would suspect it may, though there is little use for it from within C# for the reason just mentioned.
No, a constructor cannot be marked as abstract. In abstract classes constructors are usually marked as protected though, at least that's what I would recommend you doing.
Basically no.
If its abstract, you have to override it in a concrete child class, and you can't override a constructor, only overload it.
Related
This question already has answers here:
Default Interface Methods. What is deep meaningful difference now, between abstract class and interface?
(6 answers)
Closed 3 years ago.
C# 8.0 has introduced a new language feature – default implementations of interface members.
public interface IRobot
{
void Talk(string message)
{
Debug.WriteLine(message);
}
}
The new default interface implementations provides the elements of the traits language. However is is also blurring the line between what is an abstract class and what is an interface.
What is now the benefit of using an abstract class instead of an interface with default implemenation?
Funny enough, but the CLR implements default interfaces as abstract classes. CLR supports multiple inheritance. Here is a good article about this.
In C#, you need default interfaces when you need to implement (in this case actually inherit from) multiple interfaces, because the language doesn't let you inherit from multiple classes.
An abstract class also allows you to have state. State, i.e. fields, are not allowed in interfaces.
This question already has answers here:
C# virtual keyword
(9 answers)
C# - Keyword usage virtual+override vs. new
(11 answers)
Can you write virtual functions / methods in Java?
(6 answers)
Closed 4 years ago.
In an interview it was asked why do we need to override method of base class.
I tried to answer like when we want to have different implementation in derived class.
But then he said, "Why don't we just create a new method with different name and different implementation instead of overriding base class method?", anyway we are not reusing base class method as implementation will be different then just create a new method instead of overriding.
I got confused what to answer. Could somebody explain.
public class BaseClass
{
virtual void Foo(){}
}
public class DerivedClass: BaseClass
{
override void Foo(){}
}
Generally we implement overriding like above.
What he said is like why do we need concept of overriding we can do like below
public class BaseClass
{
void Foo(){}
}
public class DerivedClass: BaseClass
{
void Foo1(){}
}
His question was looking weird I tried to explain but like its a method of base class we are just redefining it in derived class. In this way our code will be clean as well. But looks like he was not satisfied.
I would check this answer:
Why does this polymorphic C# code print what it does?
then try to grasp the concept of methods in an object basically having pointers to code. When you override implementation in an subclass then that becomes the new code pointed to, whether it's used or cast as a superclass or not.
So the main purpose of overriding is to create classes that inherit from one class but each have their own implementation and then be able to treat or operate on them equally the same as the original superclass. This is the essence of the Liskov Principle or the 'L' in SOLID. What is an example of the Liskov Substitution Principle?
This question already has answers here:
Multiple Inheritance in C#
(13 answers)
Closed 4 years ago.
All similar questions I've looked though here, mentions multiple interface inheritance. However, I am not sure how MII could be a workaround to the problem.
Lets say, I have two library class (My_Class_1 and My_Class_2) of different methods. Then I want to create a new class, that can use both of these classes' methods natively, like:
public class My_Application : My_Class_1, My_Class_2 {
public My_Application(){
method_from_Class1();
smth_property_declared_in_My_Class_2 = "hello";
}
}
However, that is not possible with C#. What are flexible workarounds, to extend/enrich class with other classes? In PHP, that is unbelievably simple, just in the top of the class we can:
use example_trait_1;
use example_trait_2;
I would rather not use interfaces; in my view, they have no relation to solving this problem.
p.s. I don't want to create initialize objects for those classes. I want them to be native part of the application class.
As others mentioned, it isn't possible (because that's not what inheritance is), but it seems one workaround would be to have a public property of type Class1, inside a class that inherits Class2.
That also gets around the problem of "which class am I looking at now?" since you'd need to explicitly mention the property when you want something of type Class1.
And if you need to modify Class1 first, then you just create a separate class that inherits Class1 first, then have the public property be of that new type.
This question already has answers here:
Abstract classes and interfaces in C# [duplicate]
(7 answers)
Closed 9 years ago.
I have been provided a 3rd party DLL.
I first tried to initiate the object like so:
TestClass MyClass = new TestClass();
But Visual Studio tells me to use the Interface.
I've never done this before and don't know where to start.
The error:
The Type 'MyClass.blabla' has no constructors defined Interope type
'MyClass.Subclass' cannot be embedded. Use the applicable interface
instead.
This is likely because you're using a COM class. If that is the case, you'll most likely want to write:
ITest myTest = new TestClass();
COM wrappers frequently expose an ITest interface via a CoClass named TestClass. However, when using COM, you're (by design) typically only writing against the interface (ITest), and wouldn't want to write against the implementation directly.
It entire depends on how the TestClass is declared. If TestClass is abstract you cannot create its instance directly, instead you have to create Instance from one of the class Derived from TestClass.
TestClass test = new TestClassDerived();
where
class TestClassDerived : TestClass
{
}
It might be providing you some kind of initialization methods or being passed as constructors. You can not instantiate an abstract class or an interface the way you are trying to do (i.e. calling constructor)
This question already has answers here:
How do I check if a type is a subtype OR the type of an object?
(5 answers)
Closed 9 years ago.
Suppose I have a class that looks like this:
class Derived : // some inheritance stuff here
{
}
I want to check something like this in my code:
Derived is SomeType;
But looks like is operator need Derived to be variable of type Dervied, not Derived itself.
I don't want to create an object of type Derived.
How can I make sure Derived inherits SomeType without instantiating it?
P.S. If it helps, I want something like what where keyword does with generics.
EDIT:
Similar to this answer, but it's checking an object. I want to check the class itself.
To check for assignability, you can use the Type.IsAssignableFrom method:
typeof(SomeType).IsAssignableFrom(typeof(Derived))
This will work as you expect for type-equality, inheritance-relationships and interface-implementations but not when you are looking for 'assignability' across explicit / implicit conversion operators.
To check for strict inheritance, you can use Type.IsSubclassOf:
typeof(Derived).IsSubclassOf(typeof(SomeType))
Try this
typeof(IFoo).IsAssignableFrom(typeof(BarClass));
This will tell you whether BarClass(Derived) implements IFoo(SomeType) or not