We are currently coding directly to types instead of toward interfaces, which is not good coding practice.
The reason why we may want to change this is so that there are things that can act as other things so long as they implement the interface.
Giving an example, we have spells. Then we have spell-like things. So long as the interface for what constitutes a spell is satisfied, we could have magical things that do all sorts of things without it being a derived class of a spell type.
This also allows for things like the adapter pattern where we have things that can act as another type under certain conditions where we code to an interface and have it wrap a given object and allow us to pretend it is another. The actual use cases for this are as broad as it sounds.
For instance we can have a dungeon chest that is a type derived of the lockable chest type. This thing can spring a trap that turns the item into a mimic (which is another user story I have already created but have not implemented yet). This chest then can be wrapped and made to operate as a mobile. If necessary, the thing can then be unwrapped and "turned back into" the chest that it previously was. Say, if the chest loses sight of its intended target and wishes to reset itself.
Currently, if we were going to do the same thing, then we would need to have a monster off of BaseCreature that would need to have an extra class attribute for the type of container that it previously was and then have all of the contents of the container go into its backpack, or hold the container in a special state in its attributes and have it deleted or otherwise removed and replaced with the creature object. This would cause some additional items to be generated in order to allow for this to happen unless the chest itself can be kept in memory in the monster object and removed from the world or at least made invisible and walk throughable. Likely we would also want this to mean that the chest spawner should also not go off again until the monster is dealt with as well and be tied to it if possible.
We are currently coding directly to types instead of toward interfaces, which is not good coding practice.
The reason why we may want to change this is so that there are things that can act as other things so long as they implement the interface.
Giving an example, we have spells. Then we have spell-like things. So long as the interface for what constitutes a spell is satisfied, we could have magical things that do all sorts of things without it being a derived class of a spell type.
This also allows for things like the adapter pattern where we have things that can act as another type under certain conditions where we code to an interface and have it wrap a given object and allow us to pretend it is another. The actual use cases for this are as broad as it sounds.
For instance we can have a dungeon chest that is a type derived of the lockable chest type. This thing can spring a trap that turns the item into a mimic (which is another user story I have already created but have not implemented yet). This chest then can be wrapped and made to operate as a mobile. If necessary, the thing can then be unwrapped and "turned back into" the chest that it previously was. Say, if the chest loses sight of its intended target and wishes to reset itself.
Currently, if we were going to do the same thing, then we would need to have a monster off of BaseCreature that would need to have an extra class attribute for the type of container that it previously was and then have all of the contents of the container go into its backpack, or hold the container in a special state in its attributes and have it deleted or otherwise removed and replaced with the creature object. This would cause some additional items to be generated in order to allow for this to happen unless the chest itself can be kept in memory in the monster object and removed from the world or at least made invisible and walk throughable. Likely we would also want this to mean that the chest spawner should also not go off again until the monster is dealt with as well and be tied to it if possible.