C# 关于扩展大型 class 以提高可读性

Question

I have a large abstract class that handles weapons in my game. Combat cycles through a list of basic functions:

OnBeforeSwing
OnSwing
OnHit || OnMiss

What I have in mind is moving all combat damage-related calculations to another folder that handles just that. Combat damage-related calculations.

I was wondering if it would be correct to do so by making the OnHit method an extension one, or what would be the best approach to accomplish this.

Also. Periodically there are portions of the OnHit code that are modified, the hit damage formula is large because it takes into account a lot of conditions like resistances, transformation spells, item bonuses, special properties and other, similar, game elements.

This ends with a 500 line OnHit function, which kind of horrifies me. Even with region directives it's pretty hard to go through it without getting lost in the maze or even distracting yourself.

If I were to extend weapons with this function instead of just having the OnHit function, I could try to separate the different portions of the attack into other functions.

Then again, maybe I could to that by calling something like CombatSystem.HandleWeaponHit from the OnHit in the weapon class, and not use extension methods. It might be more appropriate.

Basically my question is if leaving it like this is really the best solution, or if I could (should?) move this part of the code into an extension method or a separate helper class that handles the damage model, and whether I should try and split the function into smaller "task" functions to improve readability.

Answer 1

I'm going to go out on a limb and suggest that your engine may not be abstracted enough. Mind you, I'm suggesting this without knowing anything else about your system aside from what you've told me in the OP.

In similar systems that I've designed, there were Actions and Effects. These were base classes. Each specific action (a machine gun attack, a specific spell, and so on) was a class derived from Action. Actions had an list of one or more specific effects that could be applied to Targets. This was achieved using Dependency Injection.

The combat engine didn't do all the math itself. Essentially, it asked the Target to calculate its defense rating, then cycled through all the active Actions and asked them to determine if any of its Effects applied to the Target. If they applied, it asked the Action to apply its relevant Effects to the Target.

Thus, the combat engine is small, and each Effect is very small, and easy to maintain.

If your system is one huge monolithic structure, you might consider a similar architecture.

Answer 2

OnHit should be an event handler, for starters. Any object that is hit should raise a Hit event, and then you can have one or more event handlers associated with that event.

If you cannot split up your current OnHit function into multiple event handlers, you can split it up into a single event handler but refactor it into multiple smaller methods that each perform a specific test or a specific calculation. It will make your code much more readable and maintainable.

Answer 3

IMHO Mike Hofer gives the leads.

The real point is not whether it's a matter of an extension method or not. The real point is that speaking of a single (extension or regular) method is unconceivable for such a complicated bunch of calculations.

Before thinking about the best implementation, you obviously need to rethink the whole thing to identify the best possible dispatch of responsibilities on objects. Each piece of elemental calculation must be done by the object it applies to. Always keep in mind the GRASP design patterns , especially Information Expert , Low Coupling and High Cohesion .

In general, each method in your project should always be a few lines of code long, no more. For each piece of calculation, think of which are all the classes on which this calculation is applicable. Then make this calculation a method of the common base class of them.

If there is no common base class, create a new interface, and make all these classes implement this interface. The interface might have methods or not: it can be used as a simple marker to identify the mentioned classes and make them have something in common.

Then you can build an elemental extension method like in this fake example:

public interface IExploding { int ExplosionRadius { get; } }

public class Grenade : IExploding { public int ExplosionRadius { get { return 30; } } ... }

public class StinkBomb : IExploding { public int ExplosionRadius { get { return 10; } } ... }

public static class Extensions
{
    public static int Damages(this IExploding explosingObject)
    {
        return explosingObject.ExplosionRadius*100;
    }
}

This sample is totally cheesy but simply aims to give leads to re-engineer your system in a more abstracted and maintenable way.

Hope this will help you !