NOTE: The language I am using is C#.
I am currently working on a ‘The Quest’ mingame where there is a player and some enemies.
My design so far involves a base abstract class called ‘Mover’ and an interface called ‘IAttacker’, since the Player object and the Enemy object(s) both move and attack, albeit in different ways. However I also think this may be unnecessary because I could just create one big combination interface, ‘IMoveAttack’ or something like that. Moreover, my friend who gave me the challenge recommeded that the Weapon class (the player can pick up weapons along the way which are lying on the floor) to be a subclass of Mover, even though the Weapons don’t really need to move, they just need to spawn at random locations at every level.
What is the best design principle in this case?
1
More interfaces are better than one big one. Make sure your concrete classes do actually need the interface. Weapon really isn’t a mover. I’d go for something like:
IMover
ISpawner
IAttacker
IDefender
Character : IMover, ISpawner, IAttacker, IDefender
Player : Character
Enemy : Character
Weapon : ISpawner
0
I’d suggest that you start by looking at Uncle Bob’s SOLID principles.
Interface Segregation – Make sure no client has to depend on methods it doesn’t use.
and Single Responsibility – Have one and only one reason to change.
If you can manage to implement those 5 design principles that’s a good start on the way to writing good code. The problems will be much easier to solve as well.