Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I know that an interface inherits another interface, and a class can inherit from another interface, but can a class inherit from another interface?
Interfaces are meant to be implemented by classes. when you declare an interface you expect to work with an instance that implements it - that instance must be a class, since you cannot instantiate interfaces.
The case when you declare an interface which inherits from a different interface is possible, and allows you to separate the responsibility of each interface, but force a class to implement all of those responsibilities
As mentioned in my comment on the question, MSDN example for implementing interfaces HERE
It's called "implementing" the interface.
If interface Inter1{} and class A : Inter1, then if class B : A, class B will also "inherit" the interface Inter1.
From Microsoft's Inheritance (C# Programming Guide)
A class or struct can implement multiple interfaces. A class can inherit a base class and also implement one or more interfaces.
So, a class:
can implement multiple interfaces (no limits)
inherits from a base class (just the one. If none is declared, the base class is object by default)
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 months ago.
Improve this question
I've tried to search for other questions like mine but I can't find any good result
I'm trying to use a DLL that has a method that need to be called with a new class but that class is abstract.
thanks.
i tried to use new IClientHandler but it just errors
You're trying to instantiate an abstract class in C# code. This is not possible, as an abstract class is a class that cannot be instantiated on its own. Instead, you would need to create a non-abstract class that extends the abstract class and then use that to create an object.
Here's an example:
abstract class AbstractClass
{
public abstract void AbstractMethod();
}
class ConcreteClass : AbstractClass
{
public override void AbstractMethod()
{
Console.WriteLine("I'm a non-abstract method!");
}
}
// Now we can create an instance of ConcreteClass
var instance = new ConcreteClass();
You can then call the AbstractMethod on the instance object, since it has been implemented in the ConcreteClass.
Also my small mistake, as #ewerspej noticed:
IClientHandler is an interface, not an abstract class. Neither can be instantiated. Interfaces require implementations that can be instantiated and abstract classes must be extended by non-abstract classes that can be instantiated.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I don't know whether this question will make sense or if it's a naive question, but I haven't been able to find a satisfactory answer.
I would like to be able to share code across multiple static classes. Is there an "equivalent" of an abstract base class for static classes (i.e. can I have one static class inherit from another one)? If not, why not? Is there another way of sharing code across multiple static classes in a manner analogous to what you do with an abstract base class?
Also, how does a static class compare to a "sealed" class?
You're quite right. Reflection will show that a static class is both abstract and sealed:
public static class MyStaticTest {
}
...
// I'm abstract
Console.WriteLine(typeof(MyStaticTest).IsAbstract ? "I'm abstract" : "");
and that's why you can't create an instance (compile time error): new MyStaticTest();. However, reflection will show that any static class is sealed as well:
// I'm sealed
Console.WriteLine(typeof(MyStaticTest).IsSealed ? "I'm sealed" : "");
and so you can't inherit from it (compile time error): public class MyClass: MyStaticTest {..}. Thus, all you can do with static class is to declare static members (static fields, properties, methods etc.)
The abstract keyword enables to create classes and class members that are incomplete and must be implemented in a derived class whereas The sealed keyword enables you to prevent the inheritance of a class or certain class members that were previously marked virtual.
I think its complete for Above
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
If you write a class and make it implement IEnumerable<out T>, you will find one method is implicit, while the other is an explicit. But our own interfaces cannot do that, so how to make our own interfaces (some methods are implicit and some explicit?)
The detailled steps are:
1) Create a class.
2) Make the class implement from "IEnumerable".
3) Choose "Implicit From the interface".
For step 3, you will find that two methods are generated:
I wonder to know:
1) Why when I choose choice 1, one method is implicit while the other is exclipit?
2) What can I do to make the Vs's intellisens act the same result, what kinds of interfaces can I define? Can you give me some samples?
Regurads!
All interface method implementations can be implemented explicitly or implicitly (see here).
The reason IEnumerable<out T> needs the GetEnumerator method to be explicitly implemented is that IEnumerable<out T> derives from IEnumerable and both interfaces have different same named methods.
What can I do to make the Vs's intellisens act the same result, what
kinds of interfaces can I define? Can you give me some samples?
Let's say you have these two interfaces:
public interface IContainer<out T> : IContainer
{
new T Value { get; }
}
public interface IContainer
{
object Value { get; }
}
Let's now define a StringContainer class that implements IContainer<string>:
public class StringContainer : IContainer<string> { }
If you hover over IContainer<string> you should see the same tooltip that shows up when implementing IEnumerable<T>.
If you click the first option - Implement Interface, Visual Studio will realize that it can't implicitly implement both members(IContainer.Value and IContainer<string>.Value) because they have the same signature.
So, VS will implicitly implement the member declared in the interface being implemented (that is IContainer<string>.Value) and will explicitly implement the inherited interface member IEnumerable.Value.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In an interface definition, is it better to declare a member of a type of the desired Class or Interface equivalent? For example, let's say we have an interface called IFoo that is implemented by the class Foo. If we are declaring another interface IBar, and we need a representation of the *Foo thing in IBar which is better?
interface IBar {
IFoo member { get; set; } // interface
}
or ...
interface IBar {
Foo member { get; set; } // class
}
There seems to be equally valid arguments for both camps. What are your thoughts?
Using an interface makes it easier to swap out the initial implementation for a new one - without having to update references since they deal with the abstraction offered by the interface.
It can also help you out with unit testing since you can easily mock based on the interface.
A common example where your code is more flexible if using an interface is IList.
Interfaces not only provide more flexibility, It also allows you to build better abstractions.
It will also force you to think of things like - If the class implements multiple interfaces, then you have to know what abstraction (Interface) is most suitable, as part of this other interface definition..
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In my program, I have defined a couple of interfaces, like IInterface1, IInterface2, IInterface3, IInterface4, IInterface5, if I need implement all five interfaces in a concrete class, do you implement those interface directly like the following
public class EntityClass: IInterface1,IInterface2, *** IInterface5
{
}
or would you create an interface which inherits from those interface firstly, and then implement that interface?
public interface IEntity: IInterface1,IInterface2, *** IInterface5
{
}
public class EntityClass:IEntity
{
}
Inheritance of interfaces expresses the "is-a" relationship. You would inherit IEntity from IInterface1 if every implementation of IEntity must also be an IInterface1.
Yes: public interface IPanda : IBear
Probably not: public interface IAccountant : IObsessiveCompulsiveDisorder
It depends on your use case.
If your IEntity always contains the other interfaces then it would be a lot easier to make it implement the others.
If this is not the case, you'll have to abstract it in a way that no class has to implement methods it doesn't need, while also needing as few implements as possible.
That being said: if you'll only use this for one or two classes, you could just as well use a list of interfaces instead of grouping them in intermediate interfaces.
Both approaches are valid in the context of good practice. However, it depends purely on your design. I find the best way to approach inheritance is to try and talk back what you are inheriting and make sure it makes sense.
For instance, "Is every EntityClass an IEntity?", which may be true. However, asking "Is every EnetityClass an Interface1, AND an Interface 2 etc.", which may be true for some instances, and not for others, but all are implemented on IEntity.
The problem with aggregating many interface implementations into one interface can be when you implement more classes off the interface that has many interfaces in itself is when the implementation needs only a few of the interfaces, in which case you need to re-work your design to ensure that the tree of inheritance makes sense.