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.
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 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)
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 8 years ago.
Improve this question
Are there design guidelines for the use of interfaces in the scenario below?
I could declare IDescription in DerivedClass or in the interface ISomeInterface or both. 3 choices, what guidelines would help me decide which is best.
public interface IDescription
{
String Description { get; }
}
public interface ISomeInterface
{
String Name { get; }
String Description { get; }
}
public class DerivedClass : Base, ISomeInterface, IDescription
{
public String Description { get; private set; }
}
It depends on the concrete interfaces and their logical relations. There is no universal solution for every case. 2 options you mentioned will be right at some cirtumstances:
If interfaces are not related (for example IDisposable and IEnumerable), then it's better that class implement two unrelated interfaces.
If interfaces are related. For example IClientAPI and IAdminAPI, then admin interface may derive from client's interface, because administrator can do everything normal user can, plus some additional operations.
The case when interfaces derived and at the same time class implements both parent and children interface is rare if at all possible in well-written code. You can always avoid it. I don't see any problems if you specify interface second time for class itself. At the same time there is no profit as well. So better don't do it.
Important note: Don't build inheritance hierarchy based on just matching property names - they can be same by coincidence. Always think if this is coincidence or fixed relation before creating base class or interface. Otherwise you'll end up with tons of interfaces like IDescription, IName, IID, etc that doesn't mean anything and only complicates the code.
If the description property is meant to represent the same semantic object in both cases, I would have ISomeInterface implement IDescription for clarity. If they are not necessarily the same thing in your design, then no.
Design guidelines basically depend on the requirement in this case. If you declare the Description in ISomewhere, then you will be forced to implement its other properties(which in this case is Name) even in the classes, which do not need the Name property.
On the other hand, if the Name and Description properties are required by all the classes where you will use ISomewhere, then it will be better to use it in single place ISomeWhere.
To get more precise answer, you need to analyze the where these interfaces will be used.
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
public class MyTokenStore: ITokenStore
{
public IToken CreateRequestToken(IOAuthContext context)
{
...some code here...
}
public IToken CreateAccessToken(IOAuthContext context)
{
...some code here...
}
}
Which one of below is better ?
Option1 - ITokenStore x = new MyTokenStore(); OR
Option2 - MyTokenStore x = new MyTokenStore()
What are the advanatges of both ?
Can I restrict user from using Option 2 ?
Users decide for themselves which version they use. The advantage of option 1 is that the user can really instantiate any class that implements the interface. Say you have a helper class that contains a method
DoSomethingVeryUseful(ITokenStore store)
then again that method becomes more useful because it can be called with any object that implements said interface.
The advantage of using option 2 is that your class may contain methods that are not part of the interface, and thus those methods can only be used with option 2.
There is no general good response to this, as it fully depends on you concrete case.
ITokenStore x = new MyTokenStore()
mades a "slice" over concrete MyTokenStore instance where not all members are inside ITokenStore, so you missing access to some additional information that may be present in MyTokenStore and is not present in ITokenStore.
On other hand you create an abstraction layer, so gain a flexibility.
The purpose of an interface is to expose functionality that is common to all implementer's and is agnostic of the concrete implementation. If you are trying to pass around multiple concrete objects to a consumer that needs to access an interface method, then cast it as an interface.
However, if you need a specific member on the concrete implementation, use that.
This is not which is better question but more what are you going to do with it ? Somethings to consider
Are you going to have multiple objects implement the interface ?
Are you going to be doing unit testing ?
Are you going to be doing any in Dependency Injection ?
If you can answer yes to at least one of the questions the using a interface is a good idea but if your using a interface just to use a interface you might want to rethink the solution
My suggestion is the below option. Instead creating "new" object, we can go with contructor injection.
public class MyTokenStore{
private readonly ITokenStore;
public MyTokenStore{ITokenStore TokenService)
{
this.TokenStore=TokenService;
}
}