【问题标题】:Is it possible to limit extension methods in a class to be of specific type?是否可以将类中的扩展方法限制为特定类型?
【发布时间】:2013-05-21 13:36:48
【问题描述】:

这一要求是由同行开发人员将不同类型的扩展方法混合到一个 xxxExt 类中的悲痛驱动的。 它仍然有效,因为编译器通过查看他导入的命名空间来处理分辨率。但是当涉及到重叠类型时,它很烦人并且不容易维护。

是否有可能限制可以在特定 xxExt 类中编写的类型扩展?循环手动规则效果不佳...如果没有编译器级别的限制,可能类似于静态代码分析?

代码(我想在这个类中限制的是 IsActiveRisk 方法)。

public static class TradeDataExt{
     public static bool IsActiveTrade(this TradeData tradeData){...}

     public static bool IsActiveRisk(this RiskData riskData) {...}


}

这更像是一个“想要的”功能,不确定是否可能。 评论/建议会很有帮助。

【问题讨论】:

  • 为什么不把这些作为public bool IsActive {get {...}} 放在TradeDataRiskData 类中?这对我来说没有意义。为什么你已经控制的类的扩展?
  • +1 @HighCore 建议
  • 确实有道理...我可能无法访问 TradeData/RiskData 库!!

标签: c# extension-methods


【解决方案1】:

首先,在我看来,您编写了示例并忘记了扩展方法中更重要的关键字,您错过了参数之前的关键字“this”! :)

我猜你的意思是:

public static class TradeDataExt
{
     public static bool IsActiveTrade(this TradeData tradeData){...}
     public static bool IsActiveRisk(this RiskData riskData) {...}
}

好了,第一点说完了,现在来看看你的问题:

此要求是由同行开发人员混合扩展的悲痛驱动的 将不同类型的方法合并到一个 xxxExt 类中。它仍然有效,因为 编译器通过查看导入的来处理分辨率 命名空间。

事实上,您所说的与扩展方法的工作原理完全相反!

当你用静态方法声明一个静态类时,当声明使用“命名空间”时,这些方法将自动可用,而不是类的名称! (除非您的项目包含多个 .cs 文件,这些文件是同一个静态类的部分类.....我认为这没有意义)

看看这个例子:

namespace Gabriel.Extensions
{
    public static class ClassWithSameName
    {
         public static bool IsActiveTrade(this TradeData tradeData){...}
    }
}

namespace John.Extensions
{
    public static class ClassWithSameName
    {
         public static bool IsAGoodDeal(this TradeData tradeData){...}
    }
}

如果您查看示例,两个类具有相同的名称,但由于它们位于不同的命名空间中,因此它们只会在显式声明每个命名空间的“使用”时扩展 TradeData 类。所以,我会说这是适合你的方式:

您应该使用命名空间来控制正在创建的类型扩展,因此您可以拥有像 XXXX.Extensions.Validation、XXXXX.Extensions.Calculation、XXXXX.Extensions.ServicesProvider 等这样的命名空间......而不是使用所有在同一个命名空间中(因为事情会变得复杂......在同一个命名空间中添加数百个扩展方法,根本不是最佳实践

您的代码应如下所示:

namespace TradeDataExtensions.Validation
{
    public static class ClassWithSameName
    {
         public static bool IsActiveTrade(this TradeData tradeData){...}
    }
}

namespace TradeDataExtensions.Analytics
{
    public static class ClassWithSameName
    {
         public static decimal ExpectedReturn(this TradeData tradeData){...}
    }
}

【讨论】:

  • 是的,错过了这个(直接在问题上输入了这个代码)。包括那个。关于命名空间,我的意思和你说的一样。用户只需要在使用中包含扩展类命名空间。这种方法看起来很实用,但又不是限制性的。
  • 嗯,老实说,这似乎是一个管理问题,而不是技术问题。为什么可以限制称为“扩展”的东西?我的观点是,您可以向开发人员指定所需的名称空间,然后强制他们使用您想要的方式。 (你甚至可以使用一些反射来测试命名空间是否只扩展了某种类型)
  • 我的意思是,如果您的开发人员想要编写一些代码,他们会这样做,除非您定义了正确的方法。即使您编写了一些反射来检查您的整个解决方案的扩展方法,他们仍然可以创建一个帮助器类并且像 TradeHelper.IsActiveTrade(trade) 那样做,您将无法控制它。您需要定义模式和标准,并且您将拥有一个准备好与您合作的团队。祝你好运:D
  • 我同意这一点。作为一名开发人员,我会比任何其他开发人员更容易听取(并同意)机器(编译器)的建议。 IMO,这同样适用于我们大多数人。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-06-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多