Should one interface inherit another interface

I can't seem to find an answer on this and just want to make sure it's an ok coding standard. I have interface A that is used by many different classes and don't want interface A to change. I came across a new requirement that will require an enum to be needed by many of the classes that implement Interface A, but not all the classes need this enum. I don't want the classes that don't require this new enum to implement this new functionality. So I created interface B that contains the new enum that I needed to add. I then made interface B inherit interface A and this is my concern, Is it ok for one interface to Inherit another interface? To continue with my changes, I then changed the classes that needed the new enum to implement interface B开发者_Go百科 instead of interface A since it was inherited by interface B. I thought about implementing both interfaces in my classes that needed them but I'm using the interface throughout the code and would like to just use one interface for looking through classes and not two.

I hope this was clear enough (probably too long) but if anyone can give me some advice on this either I'm doing it right or I'm doing it wrong please let me know.

Thanks!

Interface inheritance is an excellent tool, though you should only use it when interface B is truly substitutable for interface A, not just to aggregate loosely-related behaviors.

It's difficult to tell whether it is appropriate for your specific case, but there's nothing wrong using the practice in principle. You see it in the first-rate APIs all the time. To pick just one common example, from the .NET framework:

public interface ICollection<T> : IEnumerable<T>, IEnumerable

Consider whether the interfaces should be logically paired, and if you feel that they work well with each other then absolutely use inheritance.

Lets look at an example;

public interface IScanner
{
    void Scan();
}

public interface IPrinter
{
    void Print();
}

Printers and scanners are often separate objects, each with their own functionality however these two devices are often paired in the same device;

public interface IPhotocopier : IScanner, IPrinter
{
    void Copy();
}

It makes sense that IPhotocopier should inherit from IScanner and IPrinter as this now allows the photocopier to be used as either a scanner or printer (which it contains) in addition to its primary roll as a copier.

Now lets look at one more interface;

public interface IBlender
{
    void Blend();
}

It would not make sense to allow IBlender to be inherited by any of the earlier interfaces (what would you call them? IBlendingScanner?).

If you can't give your new interface a sensible name this might indicate that your may not want to use inheritance in this instance.

It's a bad idea to inherit some interfaces such as IDisposable, since this forces all implementations of your new interface to implement the dispose pattern even if they do not have any disposable resources.

Technically speaking, interfaces don't inherit from each other. What really happens when you create an IFoo that inherits from IBar, you're saying that any class that implements IFoo must also implement IBar.

interface IBar
{
    void DoBar();
}

interface IFoo : IBar
{
    void DoFoo();
}

In this example, the IFoo interface does not have a DoBar() method. Most of the time the distinction doesn't matter, but it can bite you when using reflection on an interface rather than a class.

It is certainly possible to have an inheritance tree of interfaces, and even "multiple inheritance" with interfaces. Whether it is the right thing to do or not depends on the interfaces in question. If it really is the case that interface B is an extension or refinement of interface A, then inheritance makes sense, but if the new enum is largely unrelated to the concept expressed by interface A, I would make them two separate interfaces and have the classes that need to implement both interfaces.

I think databases always provide a great way to demonstrate interfaces, so considering if an interface should inherit another interface look at the following,

IMySqlDatabase : IDatabase
MySqlDatabase : IMySqlDatabase

IMsSqlDatabase : IDatabase
MsSqlDatabase : IMsSqlDatabase

A MySqlDatabase IS an IMySqlDatabase and an IMySqlDatabase IS an IDatabase.

Now if you need to make changes to your IDatabase interface it's grandchildren (the conrete database classes) can reap the benefits, but you won't have to expand MySQL AND MsSQL (or perhaps even more DBMS' Interfaces). At the same time in your middle man (IMsSqlDatabase) you can still have interface features that a MySQL or Oracle DB wouldn't support.

IMO this is exactly the right approach, I don't see any problem with it.