*可以*是静态的C#方法应该是静态的吗?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/731763/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Should C# methods that *can* be static be static?
提问by Bernhard Hofmann
Should C# methods that canbe static be static?
可以是静态的C# 方法应该是静态的吗?
We were discussing this today and I'm kind of on the fence. Imagine you have a long method that you refactor a few lines out of. The new method probably takes a few local variables from the parent method and returns a value. This means it couldbe static.
我们今天正在讨论这个问题,我有点犹豫。想象一下,您有一个很长的方法,您可以从中重构几行。新方法可能从父方法中获取一些局部变量并返回一个值。这意味着它可能是静态的。
The question is: shouldit be static? It's not static by design or choice, simply by its nature in that it doesn't reference any instance values.
问题是:它应该是静态的吗?它不是静态的设计或选择,仅仅是因为它不引用任何实例值的性质。
采纳答案by Scott Wisniewski
It depends. There are really 2 types of static methods:
这取决于。实际上有两种类型的静态方法:
- Methods that are static because they CAN be
- Methods that are static because they HAVE to be
- 静态的方法,因为它们可以是
- 静态的方法,因为它们必须是
In a small to medium size code base you can really treat the two methods interchangeably.
在中小型代码库中,您真的可以互换使用这两种方法。
If you have a method that is in the first category (can-be-static), and you need to change it to access class state, it's relatively straight forward to figure out if it's possible to turn the static method into a instance method.
如果您有一个属于第一类(可以是静态的)的方法,并且您需要更改它以访问类状态,那么确定是否可以将静态方法转换为实例方法相对简单。
In a large code base, however, the sheer number of call sites might make searching to see if it's possible to convert a static method to a non static one too costly. Many times people will see the number of calls, and say "ok... I better not change this method, but instead create a new one that does what I need".
然而,在大型代码库中,调用站点的绝对数量可能会使搜索以查看是否有可能将静态方法转换为非静态方法的成本太高。很多时候人们会看到调用次数,然后说“好吧……我最好不要改变这个方法,而是创建一个新的方法来满足我的需要”。
That can result in either:
这可能导致:
- A lot of code duplication
- An explosion in the number of method arguments
- 大量代码重复
- 方法参数数量激增
Both of those things are bad.
这两件事都很糟糕。
So, my advice would be that if you have a code base over 200K LOC, that I would only make methods static if they are must-be-static methods.
因此,我的建议是,如果您的代码库超过 200K LOC,那么我只会将方法设为静态,如果它们是必须是静态的方法。
The refactoring from non-static to static is relatively easy (just add a keyword), so if you want to make a can-be-static into an actual static later (when you need it's functionality outside of an instance) then you can. However, the inverse refactoring, turning a can-be-static into a instance method is MUCH more expensive.
从非静态到静态的重构相对容易(只需添加一个关键字),因此如果您想稍后将 can-be-static 变成实际的静态(当您需要它在实例之外的功能时),那么您可以。然而,逆重构,将 can-be-static 变成实例方法的代价要高得多。
With large code bases it's better to error on the side of ease of extension, rather than on the side of idealogical purity.
对于大型代码库,最好在易于扩展的方面出错,而不是在理想的纯洁性方面出错。
So, for big projects don't make things static unless you need them to be. For small projects, just do what ever you like best.
所以,对于大型项目,除非你需要它们,否则不要让事情变得静态。对于小项目,只做你最喜欢的事情。
回答by agnieszka
Static methods are faster than the non-static ones so yes, they should be static if they can and there is no special reason for leaving them nonstatic.
静态方法比非静态方法快,所以是的,如果可以,它们应该是静态的,并且没有特殊的理由让它们非静态。
回答by Jason Punyon
I think it would make it a bit more readable if you marked it as static...Then someone who comes along would know that it doesn't reference any instance variables without having to read the entire function...
我认为如果您将其标记为静态会使其更具可读性......然后有人会知道它不会引用任何实例变量而无需阅读整个函数......
回答by Brian Ensink
It depends but generally I do not make those methods static. Code is always changing and perhaps someday I will want to make that function virtual and override it in a subclass. Or perhaps some day it will need to reference instance variables. It will be harder to make those changes if every call site has to be changed.
这取决于但通常我不会将这些方法设为静态。代码总是在变化,也许有一天我会想要将该函数设为虚拟并在子类中覆盖它。或者也许有一天它需要引用实例变量。如果每个呼叫站点都必须更改,则进行这些更改将更加困难。
回答by Michael
Not necessarily.
不必要。
Moving public methods from static to non-static is a breaking change, and would require changes to all of your callers or consumers. If a method seems like an instance method, but happens to not use any instance members, I would suggest making it an instance method as a measure of future-proofing.
将公共方法从静态转移到非静态是一个突破性的变化,需要对所有调用者或消费者进行更改。如果一个方法看起来像一个实例方法,但碰巧不使用任何实例成员,我会建议将它作为一个实例方法作为未来证明的衡量标准。
回答by Jhonny D. Cano -Leftware-
In those cases, i tend to move the method to a static or utils library, so i don't be mixing the concept of the "object" with the concept of "class"
在这些情况下,我倾向于将方法移至静态或 utils 库,因此我不会将“对象”的概念与“类”的概念混为一谈
回答by Joel Coehoorn
I would notmake it a publicstatic member of that class. The reason is that making it public static is saying something about the class' type: not only that "this type knows how to do this behavior", but also "it is the responsibility of this type to perform this behavior." And odds are the behavior no longer has any real relationship with the larger type.
我不会让它成为该类的公共静态成员。原因是将其设为 public static 是在说明类的类型:不仅“此类型知道如何执行此行为”,而且“执行此行为是此类型的责任”。而且很可能这种行为与较大的类型不再有任何实际关系。
That doesn't mean I wouldn't make it static at all, though. Ask yourself this: could the new method logically belong elsewhere? If you can answer "yes" to that, you probably do want to make it static (and move it as well). Even if that's not true, you could still make it static. Just don't mark it public
.
不过,这并不意味着我根本不会让它成为静态的。问问自己:新方法在逻辑上是否属于其他地方?如果您可以对此回答“是”,则您可能确实希望使其静止(并移动它)。即使这不是真的,您仍然可以将其设为静态。只是不要标记它public
。
As a matter of convenience, you could at least mark it internal
. This typically avoids needing to move the method if you don't have easy access to a more appropriate type, but still leaves it accessible where needed in a way that it won't show up as part of the public interface to users of your class.
为方便起见,您至少可以将其标记为internal
。如果您无法轻松访问更合适的类型,这通常可以避免需要移动方法,但仍然可以在需要的地方访问它,使其不会作为公共界面的一部分显示给您的类的用户.
回答by Foredecker
I suggest that the best way to think about it is this: If you need a class method that needs to be called when no instances of the class are instantioated, or maintains some kind of global state, then static is a good idea. But in general, I suggest you should prefer making members non-static.
我建议最好的思考方式是:如果您需要一个类方法,当没有实例化类的实例时需要调用该方法,或者维护某种全局状态,那么静态是一个好主意。但总的来说,我建议你应该更喜欢让成员非静态。
回答by 17 of 26
Making something static just because you can is not a good idea. Static methods should be static due to their design, not due to happenstance.
仅仅因为你可以而使某些东西静态并不是一个好主意。静态方法应该是静态的,因为它们的设计,而不是偶然。
Like Michael said, changing this later will break code that's using it.
正如迈克尔所说,稍后更改它会破坏正在使用它的代码。
With that said, it sounds like you are creating a private utility function for the class that is, in fact, static by design.
话虽如此,听起来您正在为该类创建一个私有实用程序函数,该函数实际上是静态的设计。
回答by JP Alioto
Yes. The reason "it can be static" is that it does not operate on the state of the object upon which it is called. Therefore it is not an instance method, but a class method. If it can do what it needs to do without ever accessing the data for the instance, then it should be static.
是的。“它可以是静态的”的原因是它不会对调用它的对象的状态进行操作。因此它不是实例方法,而是类方法。如果它可以在不访问实例数据的情况下完成它需要做的事情,那么它应该是静态的。
回答by Jabe
Yes, it should. There are various metrics of couplingthat measure how your class depends on other things, like other classes, methods, etc. Making methods static is a way to keep the degree of coupling down, since you can be surea static method does not reference any members.
是的,应该。有多种耦合度量来衡量您的类如何依赖其他事物,例如其他类、方法等。使方法静态化是一种降低耦合度的方法,因为您可以确定静态方法不引用任何成员。