-1

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?

Improve this question
1
  • Unclear what help you need. Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it’s hard to tell what problem you are trying to solve or what aspect of your approach needs to be corrected or explained. See the How to Ask page for help clarifying this question. – gnat Sep 12 '14 at 6:47
0

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
Improve this answer
0
1

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.