I assume this is largely language-agnostic, but I'm working in C# if it's notLet's say interface I3 inherits from I2, which in turn inherits from I1. I could write this:interface I1 { ... }interface I2 : I1 { ... }interface I3 : I2 { ... }Or alternatively this:interface I1 { ... }interface I2 : I1 { ... }interface I3 : I1, I2 { ... }The I1 in interface I3 is redundant - anything that implements I3 will still require anything declared in I2, which includes anything in I1.To my mind the latter is more readable - I can see at a glance all the 'base' interfaces without having to dig down the inheritance tree - but I'm not sure if it's considered good practice. Is it? Are there any hidden traps here?
Declaring 'chained' interface inheritance
interfaces;inheritance
Having deep hierarchies of interfaces is a bit of an antipattern to me. It smells of overengineering.The whole point of having interfaces is that they allow for horizontal code reuse rather than vertical (by inheritance).I don't know the context, maybe there's no way around it in your case. Perhaps it is somehow required by the framework, architecture, or otherwise by the nature of your project - eg. highly abstract code such as standard libraries.Note that this sort of redundancy can be found in .NET sources, for instance:public interface IList : ICollection, IEnumerableEven though ICollection supports IEnumerable already. Same thing with standard Java collections.What's the cost of it? Redundancy being redundancy, if one day you decide to remove the dependency I2 has on I1, you may have to do this in multiple places, or end up with an inconsistent codebase. The design does no longer follow the single source of truth principle, since the dependency of I2 on I1 is reiterated everywhere instead of stated just once.