• 10
• 12
• 12
• 14
• 16

# Is Extending Multiple Interfaces Okay

This topic is 723 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I stumbled onto this topic, and I was wondering, based on the article and the arguments being made, does an interface extending multiple interfaces violate what the article warned against when it comes to inheritance and using extends?

In Java I can do this:

public interface IGameObject {

String getGameObjectID();
String getGameObjectName();
String getGameObjectDescription();
void viewActions();
void doActionValid(String action);
boolean equals(Object obj);
int hashCode();

}
package gameprobjectpackage;

public interface IWeapon extends IGameObject {

int getWeaponDamage();
}

My reasoning is, in my game, every class that implements IWeapon, is considered an IGameObject. Is this okay based on what the article states about inheritance and extends? Did I violate any rules/best practices?

##### Share on other sites

Typically yes, it is fine to implement as many interfaces as makes sense for your design.

In Java specifically you may need to implement many different listeners, probably comparable, your own custom serializables, and more.

##### Share on other sites

extending an abstract class is fine - that's what abstract classes are for.

extending a concrete class is generally not the best choice, and is what those articles are really about. But sometimes there is good reason to do even that - take the advice of those articles as a guideline, not a law. :)

that said, extending an abstract class just to add a single getter is a little off to me. Extend it to make it do new tasks, rather than add new data.

##### Share on other sites

That's some SOLID code you have there friend!

##### Share on other sites

The equals and hashCode methods are not necessary, all of your classes get them from implicitly extending Object.

Also interface preffixes are generally frowned upon in Javaland (for example, Collection, Map and List interfaces, no preffixes).

Beyond that, extending interfaces is perfectly fine, in combination with Java 8 default methods it can be a powerful way of adding new functionality to existing code. Although I'll say that more often than not interfaces are misused. I've seen quite a few open source projects with a package filled of interfaces, and an "impl" package filled with only one concrete implementation for each interface. Most of the time you're not going to need the kind of extensibility you get with interfaces, unless you're doing a library designed to be extended (for example, the standard Java collections), and even then you'd need to know really well what you're doing.

Its really really easy to think a bunch of classes allowing extension in one direction, only to end up refactoring everything because it turns out you didn't need extensibility there but in some other place you didn't accounted for.

As always, I suggest you should try it out anyway, then suffer the consequences later  :)

Edited by TheChubu

##### Share on other sites

Do beware that hierarchies like this, particularly deep ones, are generally a lot of trouble and broadly considered a code smell. IWeapon extending IGameObject might be a fine approach, but if that continues to ISword extending IWeapon and especially if it continues further to IBurningSwordOfSmite extending ISword, then you are headed down the wrong path.

Many people like entity-component systems as an alternative to these kinds of deep hierarchies.

Class inheritance in general is overused -- interface inheritance is probably also overused, but at least has fewer dangers than with class inheritance -- and, regrettably, Java in particular more-or-less embraces this. Do use either where correct and prudent, but also be wary of over-use. You can often reduce your reliance on deep hierarchies by splitting responsibilities (e.g. embrace the single-responsibility principle), using alternative architectural approaches (Entity-Component Systems), preferring composition to inheritance, and by using data to specialize object behavior rather than inheritance.

##### Share on other sites

Do beware that hierarchies like this, particularly deep ones, are generally a lot of trouble and broadly considered a code smell. IWeapon extending IGameObject might be a fine approach, but if that continues to ISword extending IWeapon and especially if it continues further to IBurningSwordOfSmite extending ISword, then you are headed down the wrong path.

Many people like entity-component systems as an alternative to these kinds of deep hierarchies.

Class inheritance in general is overused -- interface inheritance is probably also overused, but at least has fewer dangers than with class inheritance -- and, regrettably, Java in particular more-or-less embraces this. Do use either where correct and prudent, but also be wary of over-use. You can often reduce your reliance on deep hierarchies by splitting responsibilities (e.g. embrace the single-responsibility principle), using alternative architectural approaches (Entity-Component Systems), preferring composition to inheritance, and by using data to specialize object behavior rather than inheritance.

Could you show me how you would rewrite my code using entity-component systems? Let's keep it simple with Sword bring a final class.