Should I use strategy design pattern or something else?

Question

I have recently started reading Heads First Design Pattern Book as well as coding on my final year project. In my project I am having Tanks which extends Entity. A Entity can be anything in the game which is positionable on the game map. Entity is an abstract class.

I have a move() method in my Entity class which will be used to change the position of tank. I will have a lot of different kinds of tank in my game and they will move faster or slower according to the velocity they have. Now my question is, I read about strategy pattern and according to it I should use interface for movement as I don't want to keep overriding or changing move method behaviour every time in different tanks. Maybe if a tank doesn't move I need to keep the move method empty.

So should I rather than hard-coding move() method in every Tank introduce a Movable interface in Tank class? This will be beneficial as I can change tank's movement behaviour during runtime but then I am also not sure how to do it as I may have to then introduce x and y location of tank inside the interface implementations somehow and change them accordingly. This will defeat purpose of Entity class as Entity class is used to hold x and y locations.

Please suggest me the correct way to do it.

Let me know if question is not clear because it is a bit hard to express my question as it's a bit complex.

This article http://blog.berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/ has great examples to fully understand composition over inheritance. — eddy147, Oct 15 '15 at 08:39

score 2 · Accepted Answer · edited Jun 16 '20 at 10:01

What I recommend is keeping all of your behavior in the tank, but keep the parameters such as velocity in another object. It would look something like this, in pseudocode:

interface TankParameters {
  int getVelocity();
  int getArmor();
  int getAttackPower();
}

class Tank : Entity {
  private TankParameters parameters;
  private Point location;

  public Tank(TankParameters p) {
    parameters = p;
  }

  public void move(Direction d) {
    // Use the direction, velocity on the parameters object,
    // something else like time and calculate the new location.
  }
}

You can have a single Tank class but alter the behavior of each Tank object by passing in different parameters at construction time.

This is a form of Dependency Injection: while the TankParameters class is not technically a dependency because it is contrived and exists solely to break up the responsibilities of the Tank class, the idea of passing in arbitrary objects to alter behavior is a cornerstone of DI.

This is not quite a strategy, simply because TankParameters does not actually contain any algorithms. It exists to externalize data not behavior.

While not strictly part of your question, I would also change Entity to be an interface and use composition instead of inheritance. The links below go into more detail about the benefits of using this approach.

Should I use strategy design pattern or something else?

1 Answers1

See Also

Linked