Converting public method to extension method

Question

In my project's core library we have a very big class, which is tending to become a God object. One of the reasons is that, over a period of time, tasks which should have been in different modules have been put into this class. For ex -

class HugeClass{
    public void DoModuleXJob(){}
    public void DoModuleYJob(){}
}

One of the problems in refactoring and moving the unwanted, module specific behavior out of this class is that it will be a lot of work for Module X and Module Y to change their code. As a work around I was thinking about converting these methods into extension methods and then move them to their concerned modules. For ex -

// in module X
static class HugeClassExtensions{
    public static void DoModuleXJob(this HugeClass instance){}
} 

// in module Y
static class HugeClassExtensions{
    public static void DoModuleYJob(this HugeClass instance){}
}

I found that this does not create any compilation problems, as long as Module Y is not using DoModuleXJob and vice-versa, which I am sure about.

Is this a good solution and are there any better methods in such a case?

Answer 1

Extension methods is just a "syntax sugar". You can define common static method and make HugeClass instance one of it parameters. So it is no difference. CIL file after compilation will be the same.

Answer 2

This is not a bad intermediate step, as it at least gives you a way to partition out the functionality and prove that there are no method inter-dependencies between the extension 'modules'. That's a great first step toward creating true subclasses, though it's still not ideal (you can't instantiate the module classes individually for unit testing.)

Once you have this partitioning, it should make it easier to create new classes, as you've already identified the module boundaries. The process would go like this:

1. The parameter passed to the extension method becomes a field on the new class, which is set in the constructor.

2. All of the extension methods become methods of the new class.

3. You can now extract an interface for the main class, so the sub-classes no longer depend on the full implementation. In some cases, you might be able to further reduce dependencies by breaking the functionality into multiple interfaces

4. Now that you have dependency isolation through interfaces, you can write unit tests for individual modules.

Answer 3

I see your design is different, but why you did not use the Workflow Foundation 4.0? It's easy and flexible. You can write your code as CodeActivity in workflows. I think you can suppose a workflow (Activity) as a new module job which could be added to the core.

More over you can dynamically generate the workflows (Activities) which will be very useful.

(Excuse me for my bad english)

Answer 4

I would suggest that you create the design as it should be, moving the functionality that is in HugeClass to the spot that it should be, and then leave the method call in HugeClass but have it defer to the functionality to where it was moved:

class HugeClass
{
    [Obsolete("Use ModuleX.DoModuleXJob() instead", false)]
    public void DoModuleXJob() {
        ModuleX mod = new ModuleX();
        mod.DoModuleXJob();
    }
}
class ModuleX
{
    public void DoModuleXJob() {
    }
}

In this way over time you are employing the Facade Pattern with HugeClass. The Obsolete attribute that I have applied to the HugeClass method means that every time something is compiled that calls the method in HugeClass a warning will be generated, pointing to where the new functionality is. The 'false' parameter in the attribute is what makes it a warning, this could be changed to true to make it an error. In this way you are not doing much extra work and it represents progress to where you want to be, which I don't believe your extension method technique would do necessarily. Over time the methods in HugeClass can be deleted until it is an empty class and itself can be deleted.

Incidently, if you have not read Martin Fowler's book Refactoring it is an excellent read. In it he discusses this and many other techniques.