How to replace if/else/switch with polymorphisim

Question

For a long time Robert Martin has been advising against if/else/switch branching logic and instead rely on the polymorphic behavior of different types. if/else/switch should only be used in the factory creating the types with different behaviours. He describes the approach in a recent blog post. I feel I understand the thrust of his argument as applied in his example situation and I really like the concept as it pushes decision making to a single location, DRY & OCP.

However, I'm finding it difficult to apply the principle is some basic game dev situations.

e.g. consider this pseudo-code controlling a ball bouncing around a box (think 'Breakout')

void ball::update(){
  if(collideswith(leftWall))
    velocity.x= +speed;
  else if(collideswith(rightWall))
    velocity.x = -speed;
  else if(collideswith(topWall))
    velocity.y = -speed;
  else if(collideswith(bottomWall))
    velocity.x = +speed;
}

I am unsure what kind of polymorphic class I could build to replace the branching logic here.

Replacing the above code with an Uncle Bob solution might be over-engineering, but am interested in learning more about applying the principle in these kinds of contexts.

Answer 1

I'll just cover the is_key_pressed I proposed in comments.

You could have a list of input handlers strategies. It would be a list of key-value pairs. Where they key is… well, a key, that could be pressed. And the value is what happens when the key is pressed.

You would have the type of the values be IInputStrategy (or IHandleInput using lolcat interface name convention). And you have multiple implementations, such as JumpStrategy, RunStrategy, ShootStrategy, and so on. Then you iterate over the list, for each one check if it the key is pressed, and call Execute on the value. Like this:

for ((key, strategy): strategies))
{
    if (is_key_pressed(key))
    {
        strategy.Execute(avatar);
    }
}

This has the advantage that we can easily add commands and change their binding in runtime. For example to configure the input we can just modify the key. Perhaps we can add or replace elements when the player unlocks a power up, or something like that. It also has the advantage of keeping the code for each command separate.

We could also wrap the calls to is_key_pressed in other objects. That could allow to configure inputs not based on a single key press. Then we can rewrite the code like this:

for (IInputStragy strategy: strategies))
{
    strategy.Execute(avatar);
}

That looks like a suitable replacement for a series of if statements. However, if we have a switch, we want to stop at the first one. So let us have Execute return bool:

for (IInputStragy strategy: strategies))
{
    if (strategy.Execute(avatar))
    {
        break;
    }
}

Well, that is not entirely disimilar to sequence and selector in behavior trees. That could be the path forward to continue to evolve this solution.

Answer 2

The OOP way to do this, would be to give the class wall a method handleCollision(ball) (although instead of ball, you might want to use the base-class of ball which represents any object which has a velocity and can bounce off of things).

And because you have both horizontal walls and vertical walls which do different things when a ball collides with them, you would create two classes inheriting from wall, namely verticalWall and horizontalWall. These classes would provide different implementation for handleCollision. One of them doing ball.velocity.x *= -1; and the other ball.velocity.y *= -1. leftWall and rightWall would be of type verticalWall and topWall and bottomWall would be of type horizontalWall.

You likely don't just want to limit yourself to 4 walls in your game but allow any number of walls, so it might be better to store those walls in an array. That allows you to write code like that:

for (wall w: walls) {
    if (collidesWith(w) {
        w.handleCollision(this);
    }
}

The array walls can contain any mix of horizontal and vertical walls, and the wonder of polymorphy will make sure that the correct handleCollision method is called for each of them within this loop.