interface IPlayer { void LevelUp(); }
class Character : IPlayer { public void LevelUp() { _level++; }
class Ship : IPlayer { public void LevelUp() { _level++; _armor++;}
class Mech : IPlayer { public void LevelUp() { _level++; _guns++;}
// instead of having a list of Characters, or Ships, or Mechs, we can have a list of IPlayer
List<IPlayer> playas = new List<IPlayer>();
foreach(IPlayer ch in playas) { ch.LevelUp(); }
foreach (IPlayer ch in playas) {
if (ch is Character) {
Character c = (Character)ch;
c.MethodOnlyBelongingToCharacter();
c.LevelUp();
} else ch.LevelUp();
}
interpreter) I've decided that it would be much more logical to first create the mud's library.
After studying up on inheritance, polymorphism, and composition, I'm a bit confused. Here's why:
Inheritance:
I've read that inheritance can "break encapsulation" if used improperly. I can see that having too
strict of a class hierarchy may lead to things becoming rigid along the way. A MUD is a good example
of system that requires scalability (you never know what you might want to add later).
Questions: How many derived classes is too many? Should base classes be avoided?
polymorphism: - specifically using interfaces (as in Java or C# structures)
The more I learn about Interfaces, the more I like them. But while going down this road, there
are some concerns along the way. One that comes to mind, is that if you implement class methods
without an interface, you are almost doing yourself a disservice. This could apply to any class
that could have similar behavior to another later on. So where do you draw the line? If I had
a Character class, and I were to implement IMoveable for instance, any user-controlled object
could implement the IMoveable interface and the object would "move()" or what have you. But if
I were to create a move() method for Character on it's own, it wouldn't be able to do something like:
Not because Character does not have move(), but because Character is not shared type IMoveable.
Questions: Where do you draw the line on interfaces? Would it make most sense to always use them, even if you don't see any reason to create
objects with similar behavior at the time?
Composition:
Although this is it's own subject, it sort of ties together my concerns.
An example would be a Character or similar Entity's inventory:
1) You could use composition by creating an InventoryHelper object that could be utilized by anything in the game.
2) You could create an interface like ICarriesItems and have each entity class implement it's own features.
3) You could have all entity's inherit the base class EntityBase which would take care of the inventory.
Questions: How do you avoid the complexity of embedding objects that could very well be derived classes themselves? What are the main
benefits of composition?
Summary:
I am open to all viewpoints as this is probably more opinion based than anything. But I would also like examples of why you think one way is better than the other. My goal is to take in all points of view, and get past this hurdle.