我应该更喜欢 C# 中的静态方法吗
在花了一些时间学习函数式编程之后，我越来越自然地想要使用不执行任何突变的静态方法。
我有什么理由应该抑制这种本能吗？
Having spent a bit of time learning about functional programming, it's becoming more and more natural for me to want to work with static methods that don't perform any mutation.
Are there any reasons why I should curb this instinct?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我觉得这个问题有点奇怪，因为静态方法和不执行突变的方法是方法的两个正交分类。您可以拥有可变静态方法和非可变实例方法。
对我来说，将函数式编程和面向对象编程结合起来已经变得越来越自然；我喜欢不执行任何突变的实例方法。函数式编程更容易理解，因为它不鼓励复杂的突变； OO 编程更容易理解，因为它所操作的代码和数据是紧密相连的。为什么选择？拥抱“和”的力量；两者都做！
The question I find a bit odd, because static methods and methods that perform no mutations are two orthogonal classifications of methods. You can have mutating static methods and nonmutating instance methods.
For me, it has become more and more natural to combine functional and oo programming; I like instance methods that perform no mutations. Functional programming is easier to understand because it discourages complex mutations; OO programming is easier to understand because the code and the data it operates on are close together. Why choose? Embrace the power of "and"; do both!
您可以用这种方式编写工作程序，但这不是惯用的。如果你想在团队中工作，我会尽力限制它。如果没有其他人读你的代码，那就发疯吧。
You can write working programs this way, but it's not idiomatic. If you want to work on a team, I'd try to curb it. If no one else is reading your code, go nuts.
出于某种原因，当我读到你的问题时，我想起了这句话：
如果 C# 的目的是纯粹的函数式，那么
static就没有必要了，因为默认情况下一切都是静态的。如果您严格遵循 OOP 实践和 SOLID 原则，您的代码将有效地发挥作用（我知道某处有关于此的引用），因此您最终会获得两全其美的效果。我之所以在多用户项目中限制它，是因为它不是典型的 C#（它实际上是带有手铐的 C#）。你只需要一个人打破规则并声明一个静态可变属性，一切都会变得糟糕。
For some reason I think of this quote when I read your question:
If the intent of C# were to be purely functional,
staticwould be unnecessary because everything would be static by default. If you are strict about following OOP practices and the SOLID principles, your code effectively becomes functional (I know there's a quote out there about this somewhere) so you end up getting the best of both worlds.The reason I would curb it in a multi-user project would be that it's not typical C# (it's really C# with handcuffs). You just need one person to break the rule and declare a static mutable property and everything goes to hell.
不完全。我确实喜欢我的扩展方法和 Linq，但是 OO 语言应该以 OO 方式使用。此外，这对于 CPU 以及其上的几个层来说都是必需的。
Not completely. I do like my extension methods, and Linq, but an OO-language should be used in an OO fashion. Besides, it's all imperative at the CPU, and for several layers on top of that.
很好的问题。
我认为答案取决于代码执行的上下文以及其中有多少是静态的。
自从我现在对接口进行大量编程并将一些方法标记为“受保护的虚拟”而不是“静态”（例如单元测试的提取和覆盖模式）以来，我的代码看到的静态情况越来越少。但这并不是说您不能直接从这些方法中调用静态方法。
Great question.
I think the answer depends on the context of what your code does, and how much of it is static.
My code has been seeing less static cases since I program to interfaces a lot now and mark some methods 'protected virtual' rather than 'static' for cases such as unit testing's extract and override pattern. Thats not to say you couldnt just call static methods from those, though.
老邮报只需再花 2 美分。静态字段/属性/方法/类就可以了。对我来说，助手类几乎一直是静态的。他们使用方法中过去的数据执行某种操作。静态类可以充当某种“单一”数据对象。如果结果证明很方便，就使用它。更重要的是，您编写的所有静态内容都符合清晰的架构、干净且可维护的代码的宏伟计划。 OOP、静态、函数、模式等等……都是创建潜在优秀代码的工具。
Old Post just another 2 cent. Static fields/properties/methods/classes are just fine. Helper classes, for me, are almost static all the time. They perform some kind of operation with or on the data that is past in there methods. Static classes could act as some kind of 'singleton' data object. If it turns out handy just use it. Much more important is that all static you write is fitting in the grand scheme of clear architecture, clean and maintainable code. OOP, static, funcional, patterns, list goes on... are just tools to create potentially great code.
当您编写 OOP 时，有很多原因应该抑制这种本能。
对象状态和行为；
静态类和方法需要参数，您应该确定哪些参数将传递给静态方法。但是如果与状态相关的方法，类会自行管理。
我认为仅这个理由就足以遏制static修饰符。
出于明确的原因，我们应该听利斯科夫夫人的话。 此处
There is many reasons should curb this instinct when you write OOP.
Object states and behaviours;
Static class and method need parameters, and you should be sure which paramters will pass to static methods. But class manages itself if method related with is state.
I think that only this reason enough to curb static modifiers.
And for clear reason, we should listen Mrs. Liskov. here