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?

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.

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.

That's some SOLID code you have there friend!

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.