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.
Related
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?
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I'm having some troubles making an interface for my class. I tried with a simple public void and that worked. But i cannot get it to work with the public static voids in the code below. I think it has something to do with the enum as a parameter in the method. But How do i fix this?
This is the class:
And this is my interface:
Interfaces are contracts. They specify the method signatures for all methods within the contract.
In your interface, you have:
void FFT(/*stuff*/)
Yet, in your implementation, you have defined
static void FFT(/*stuff*/)
Now, why can't we use static? From Joel Spoelsky
Because an interface is a "contract" or an agreement between the consumer (caller) and the provider (callee). An interface describes what and how the calle will provide functionality. There is no need for static members provided by a third party. Static members cannot be overridden by a provider so they do not belong in an interface.
Interface is a contract between caller and callee. Static member belong to class not to the object, so its no point of making method static.
To explain why this really doesn't make sense, the reason to make an interface is so you can pass an object of your class as a reference to the interface type, so the consumer doesn't need to know which underlying type the object is. For example, you might pass an IEnumerable<Foo> to a method that doesn't need to know or care if this is an array or a list or a hashset, etc., it just wants a sequence of Foos.
Static methods are not associated with an instance, so there is no object to reference. There isn't the concept in C# of a static interface which could be used to reference a class rather than an object.
If you had other classes that you wanted to use interchangeably, you could get rid of the static and make these singletons.
This question already has answers here:
Is it possible to have a compile time check that a type is marked with the Serializable attribute
(2 answers)
Closed 9 years ago.
I have a [Serializable] class in C# that has many fields, each a different class. I use serialization to save/load instances of this class but it happens often to me that I forget to add a [Serializable] attribute somewhere and only learn this at runtime. Can this be checked during compilation?
For example, this code,
[Serializable]
class House {
List<Room> Rooms;
}
class Room
{
}
should not pass the validation because the Room class is not serializable.
No, there's nothing you can do at compile-time.
However, it's easy to add a unit test for this - you could find each serializable class within your assembly, and recursively find all fields and check that each one is serializable. Of course, a simpler approach would simply be to serialize an instance :)
A unit test isn't as good as a compile-time check, but it's better than only doing it "live".
There is no way to determine if a type is serializable or not at compile time. For types that implement ISerializable this can be done by restricting an API to take only ISerializable. But this doesn't work for the types decorated with [Serializable] because you can't constrain an API to take types which have a specific attribute applied to them
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
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.