CodeRush 建议将具有参数的方法设为静态，同意还是不同意？

发布于 2024-12-15 04:04:11 字数 293 浏览 5 评论 0原文

我使用 Developer Express 的 CodeRush 产品，该产品有一个名为“代码问题”的功能，可以提出优化代码的建议。我注意到，如果您有一个带有参数的方法，它总是建议将此方法设为静态。本着尝试编写最好的代码并进行优化（我认为这就是 DevExpress 试图帮助我们做的事情）的精神，我听到了关于使方法静态是否实际上明智的不同意见。

您对于什么时候方法应该是静态的有何看法？这样做有什么好处吗？影响？我没有看到它有什么问题，因为它需要参数来运行该方法，因此这不会成为跨多个用户/用途的问题。

好还是坏？

谢谢。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一人独醉 2024-12-22 04:04:11

方法是否有参数与它无关。唯一的考虑因素是该方法是否尝试访问类的任何非静态（即基于实例的）成员，或者类中的其他静态成员是否调用它......

例如

 private static int Add(int a, int b) 
 { return a + b; }

可以是静态的 - 它不访问其容器类的任何实例成员，即使它有参数

但在下面的类中，PrintHello() 不能声明为静态，因为它访问基于实例的字段 useCount >，即使它没有参数。

public class myClass
{
    private int useCount = 0;

    private void PrintHello()
    { 
        useCount = useCount + 1;
        Console.Write("Hello");
    }
}

Whether or not a method has parameters has nothing to do with it. The only consideration is whether the method attempts to access any non-static (i.e., instance-based ) members of the class, or if some other static member in the class calls it....

For example

 private static int Add(int a, int b) 
 { return a + b; }

can be static - it does not access any instance members of its container class, even though it has parameters

But in the following class, PrintHello() cannot be declared as static since it accesses the instance-based field useCount, even though it has no parameters.

public class myClass
{
    private int useCount = 0;

    private void PrintHello()
    { 
        useCount = useCount + 1;
        Console.Write("Hello");
    }
}

回复收藏 0 原文

难以启齿的温柔 2024-12-22 04:04:11

正如其他人所指出的，参数的存在不是一个考虑因素。
当该方法不访问任何实例成员时，就会出现提示。

什么时候有用？

当候选方法不需要状态来执行其功能时，不应要求该函数的调用者拥有或创建父类的实例。

通过删除此要求，调用代码将显示错误（或在某些语言中为警告），指示相关方法“无法通过实例引用访问”，需要类型引用。

当重写调用语句以使用类型引用时，可能会发现不需要该类型的原始实例，并且可以进一步重构代码以消除相同类型的创建。

消除该实例类型将节省 cpu 和内存。

调用方法（或其自身的调用者）可能会更容易阅读，因为相关方法不需要实例化代码。

此外，如果缺少实例化代码，这将增加一个或多个方法的可读性。

例如，System.Math 类是静态的，因此充满了静态函数。如果这些函数的调用代码必须在执行之前实例化数学类的实例，那么其可读性就会较差。

回复收藏 0 原文

染年凉城似染瑾 2024-12-22 04:04:11

我通常会避免使用静态方法，因为它们很难与单元测试和依赖项注入一起使用。（我知道打字机）。
只有当该方法被紧密包含时，我才会考虑使用静态方法。

回复收藏 0 原文

丢了幸福的猪 2024-12-22 04:04:11

就我个人而言，我对这个问题有两种看法。

一方面，有人可能会认为该方法应该设为静态，因为它不访问任何实例成员。虽然这有一定道理，但我并不总是急于去做这件事，有几个原因：

命名空间污染。如果我们养成这种习惯，它就会开始带有“美好时光”的味道，那时所有东西都集中到全局模块中，你可以随意调用函数。我一想到这里就不寒而栗。诚然，静态方法被组织成类和命名空间，但它们仍然不是特定于实例的，对我来说它们只是全局函数的味道。它们让我的脚趾卷曲，就像指甲划在黑板上的声音。
仅仅因为方法今天不访问实例变量并不意味着明天也不会。为此进行重构是一个重大更改。将方法设为静态并不是一个应该轻易做出的决定。您这样做是因为您知道该方法旨在以这种方式使用，而不是因为工具注意到今天您没有使用实例变量。

话虽如此，我确实相信静态方法具有非常有用的用途，并且如果使用得当，可以出色地解决无数问题。当我打算使用它们时，我会为了非常具体的目的而使用它们，而这些目的通常与 Resharper 是否认为我应该这样做无关。

我还没有看到任何内容表明如果将方法标记为静态，应用程序将更有效地执行。我可能倾向于认为静态类会降低性能，因为它们在应用程序的生命周期中存在，并且它们分配的任何资源在应用程序超出范围之前不会被释放。（另一方面，根据实施情况，这可能会导致性能提升。）

最终，性能问题归结于实施。