代码之家 › 专栏 › 技术社区 › Unmesh Kondolikar

将公共方法转换为扩展方法

public-method extension-methods c#

1

Unmesh Kondolikar · 技术社区 · 15 年前

在我的项目的核心库中,我们有一个非常大的类,它倾向于成为 God object . 其中一个原因是,在一段时间内,应该在不同模块中的任务都被放入这个类中。用于ex-

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

重构并将不需要的、特定于模块的行为移出这个类的一个问题是,模块X和模块Y更改它们的代码需要做很多工作。作为一项工作,我正在考虑将这些方法转换为扩展方法,然后将它们转移到相关模块。用于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){}
}

我发现这不会造成任何编译问题,只要模块Y不使用DoModuleXJob,反之亦然,我确信这一点。

这是一个很好的解决方案吗?在这种情况下,还有更好的方法吗?

4 回复 | 直到 14 年前

1

Dan Bryant 15 年前

这是一个不错的中间步骤,因为它至少为您提供了一种方法来划分功能,并证明扩展“模块”之间没有方法间的依赖关系。这是朝着创建真正的子类迈出的第一步,尽管它仍然不理想(您不能为单元测试单独实例化模块类)

一旦有了这个分区,就应该更容易创建新类,因为您已经确定了模块边界。过程如下:

传递给扩展方法的参数成为新类上的字段,该类在构造函数中设置。
所有的扩展方法都成为新类的方法。
现在可以为主类提取接口,这样子类就不再依赖于完整的实现。在某些情况下,您可以通过将功能分解为多个接口来进一步减少依赖关系
现在您已经通过接口隔离了依赖关系,可以为各个模块编写单元测试。

2

0

Andrey Stukalin 15 年前

扩展方法只是一种“语法糖”。您可以定义公共静态方法,并将HugeClass实例作为其中一个参数。所以没什么区别。编译后的CIL文件将相同。

3

0

Amir Karimi 15 年前

我看到你的设计是不同的,但为什么你没有使用工作流基础4.0?它简单灵活。您可以在工作流中将代码编写为CodeActivity。我认为您可以将工作流(活动)假设为可以添加到核心的新模块作业。

此外,还可以动态生成非常有用的工作流(活动)。

(请原谅我英语不好)

4

0

Steve Ellinger 15 年前

我建议您按原样创建设计,将hugclass中的功能移到它应该的位置,然后将方法调用留在hugclass中,但要让它遵从它移到的位置:

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

随着时间的推移,你在雇佣 Facade Pattern 和雨果。这个 Obsolete attribute 我对HugeClass方法的应用意味着每次编译调用HugeClass中方法的东西时,都会生成一个警告,指出新功能的位置。属性中的“false”参数使其成为警告,可以将其更改为true以使其成为错误。这样你就不会做太多额外的工作了,它代表着你想要达到的目标,我不相信你的扩展方法技术一定能做到。随着时间的推移,HugeClass中的方法可以被删除,直到它是一个空类并且它本身可以被删除。

顺便说一下,如果你没读过马丁·福勒的书 Refactoring 这是一本很好的书。在书中他讨论了这个和许多其他的技巧。