C# 在非静态类中使用静态方法是否有正当理由?

C# 在非静态类中使用静态方法是否有正当理由?,c#,.net,C#,.net,标题几乎是我的全部问题 我正在为一个在非静态类中有几个静态方法的离岸开发人员进行代码审查。在我挑战开发人员并将其标记为“需要更改”之前,我只想确定一下 我理解静态类的用途:它不能实例化,可以直接使用。但我看不出有任何理由在非静态类中使用静态方法。这方面是否有任何有效的用例 所讨论的方法都是私有的,并且是从非静态方法调用的 下面是一个例子: public ViewResult ClaimDetails(ClaimDetails claim) { if (claim.

标题几乎是我的全部问题

我正在为一个在非静态类中有几个静态方法的离岸开发人员进行代码审查。在我挑战开发人员并将其标记为“需要更改”之前,我只想确定一下

我理解静态类的用途:它不能实例化,可以直接使用。但我看不出有任何理由在非静态类中使用静态方法。这方面是否有任何有效的用例

所讨论的方法都是私有的,并且是从非静态方法调用的

下面是一个例子:

    public ViewResult ClaimDetails(ClaimDetails claim)
    {
        if (claim.ClaimNumber != 0)
        {
            claim = Get_ClaimDetails(claim);
        }
        return View("ClaimDetails", claim);
    }

    private static ClaimDetails Get_ClaimDetails(ClaimDetails claim)
    {
        ClaimsRepository claimsRepository = new ClaimsRepository();
        _claimDetails = new ClaimDetails();
        _claimDetails = claimsRepository.GetClaimDetails(claim.ClaimNumber);
        return _claimDetails;
    }

例如,在不希望公开内部实现的情况下,使用多个静态工厂方法是一种常用的方法

Car hatchback=Car.CreateHatchback();
Car sedan=Car.CreateSedan();

在本例中,两个实例都有工厂方法的隐藏内部实现,可能实例化专门的内部子类或调用内部构造函数。

有一些事情会让我感到惊讶,但方法签名很好

static
是确保方法不使用实例成员的关键字。太好了。它清楚地向其他开发人员发出了这一信号。我会提出相反的观点:方法应该标记为静态,除非需要其他方法

如果您没有将其标记为static,许多工具甚至VisualStudio本身都会将其标记为static

引用微软:

不访问实例数据或调用实例方法的成员可以标记为静态(在Visual Basic中共享)。将方法标记为静态后,编译器将向这些成员发出非虚拟调用站点。发出非虚拟调用站点将阻止在运行时对每个调用进行检查,以确保当前对象指针非空。这可以为性能敏感的代码实现可测量的性能增益。在某些情况下,无法访问当前对象实例表示存在正确性问题

所以总结一下:现在一切都很好



阅读所有附加注释:看起来真正的问题是注入的存储库已经存在,整个方法应该废弃,并替换为行
claim=this.injectedClaimsRepository.GetClaimDetails(claim.ClaimNumber)。但这是另一个问题。如果使用正确,关键字
static
是非常好的,张贴的代码没有显示它不是。

这与
公共汽车(CarType CarType)
有什么不同?这还隐藏了构造函数接口后面的任何内部实现。我可以调用100个内部构造函数,但没有绑定到公共接口的人会注意到。@MarkusDeibel:您假设
CarType
是唯一的区别。如果不止一个值,那么隐藏精确实现的价值就大得多,这就是工厂模式存在的原因。当然,这个答案是使用穷人的工厂,避免使用实际的工厂类,而是对类本身使用静态方法;但功能目的仍然是一样的。公共构造函数并不总是最好的方法,特别是当存在复杂或高度重复的初始化逻辑时。好的,谢谢!我在这里学习。所以总的来说,你的答案是有道理的。现在。。。在这种特定情况下,开发人员正在(重新)创建一个已注入控制器的存储库。虽然这是可行的,但让方法非静态并使用注入的存储库不是更有意义吗?@CaseyCrookston的确,如果已经存在注入的存储库,我会说整个方法应该被删除。谢谢!在您更新之后,我将此标记为答案,因为它涵盖了一般问题和特定实例。非常感谢!评论不用于扩展讨论;这段对话已经结束。