shoftee/JavaStory — comment on commit d2b5df08cdd059381177a48ea0c4f67d78ed06b0
File: Core/src/main/java/javastory/channel/maps/GameMapInfo.java line 87
By shoftee:

I can't remove the one from the other class because the logic there is using it. This class, the replacement, happens to need the same method. If I was planning to use it in both places I would extract it in a separate class. The method doesn't refer to any class members so technically it could be extracted as a utility method somewhere, making inheritance moot. And inheritance would make no architectural sense here.

When I finish this class I'll remove the other. And I'm a bit iffy about keeping this one here anyways, might move it into FootholdTree. Dunno.

On a side note, inheritance is by far not the only way to reuse code ;)
In fact it's one of the worse ones, because it requires you to derive from a class to reuse the logic. And you can only derive from one of them in Java, so what happens when you wanna reuse logic from two classes? What you usually should do is compose, not inherit.

This thing is actually a pretty good example of composition over inheritance.
You will notice this pattern come up in many places around the code, it's there for Reactor, Npc, Monster, and a few others, basically things that have a (static) game data part and a (dynamic) instance part. This is surprisingly not the case for Map and Item, which leads to the huge thing you see in GameMapFactory and the complicated logic around items as well (which I plan to fix in the near future).
So what you wanna do is, have a class that stores just the loaded static data - you know for sure that the data will never change, so you are free to cache instances of this class. Classes of this nature usually have a lot of loading logic like what you see here.
When you have an "instance" class, however, you don't want the loading logic in it - you have no use for it there - so inheriting the class would be a weird choice. You do however want the loaded data.
The correct choice in this case is to have a class member that holds the loaded data. That's what we call composition - you compose one object into another, like files into folders. Whenever you need to access the loaded data, you access the cached object that you have a reference to. The only one. Instead of loading the same data into memory again a thousand times over.
Maps are not a good choice for this exact example, since you don't really load that many instances of the same map. Items are better.