Two ways to avoid a large amount of similar sub-classes

Is it is bad practice in Object Oriented Design to subclass multiple classes from a single base class?

Say for instance you are designing a game and you have several different monsters you might come across. The approach I would take is to have a base abstract class for just a general monster object and then subclass all of the specific types of monsters from the base class using a new class.

One of my instructors told me that you shouldn't rely on inheritance in this case because the number of monsters will continue to grow and grow and the number of classes will increase to a point where it is hard to keep track of all of them and thus you will have to recompile the program with every new class added in the future.

My answer:

If monsters are very similar, in that the only differences are (for example) their name, how much damage they impart, what color they are, etc., then these differences which can be reflected in a field (in values), may make sub-classing unnecessary.

If, however, you have monsters that are fundamentally different from others, such that it is necessary to have very different methods and logic, and more specifically, differences that cannot be reflected in fields, then a sub-class SpecialMonster may be necessary.

But again, even SpecialMonster may not need to be sub-classed by individual monster types, as it’s fields may be enough to distinguish between them.

While it’s legal to have a million sub-classes of specific monster types, you don’t want to take care of all that duplicate code when it could simply be expressed in the fields of new Monster instances, such as

There is an alternative, where you do have a lot of classes, but you don’t impose them onto your users, and you don’t clutter up your API/JavaDoc with them. If your Monster happens to be an abstract class