But this comes with a raft of problems. The least of which is when the combat system changes, the monster will need updating.

2) A better approach is to refer to an interface for combat systems rather than a particular implementation. This will save on the refactoring. The monster can also ask a factory for the combat system that implements this interface. This adds a dependency on a factory however, which is not ideal.

So instead we inject the combat system into the monster. This is known as dependency injection and removes the monster's dependency on a concrete combat system or factory.

Control has shifted to the combat system now. It references the monster and will make the required calls to resolve the combat. This is known as inversion of control (IoC) or the Hollywood principle - "Don't call us, we'll call you".

In hindsight it's easy to see we had things backwards from the start, but the direct approach is all too common. It's a hangover from procedural programming where the programme's flow of control acts directly rather than setting up an object model and then handing over control to one of these objects.

In this way, the combat system and the monster are much easier to maintain, test and debug.