我应该更喜欢 C# 中的静态方法吗答案

【问题标题】：Should I prefer static methods in C#我应该更喜欢 C# 中的静态方法吗
【发布时间】：2011-02-07 23:01:03
【问题描述】：

在学习了函数式编程之后，我越来越想使用不执行任何突变的静态方法。

我有什么理由要抑制这种本能吗？

【问题讨论】：

【解决方案1】：

我觉得这个问题有点奇怪，因为静态方法和不执行突变的方法是方法的两个正交分类。您可以拥有可变静态方法和非可变实例方法。

对我来说，将函数式编程和oo编程结合起来已经变得越来越自然；我喜欢不执行突变的 instance 方法。函数式编程更容易理解，因为它不鼓励复杂的突变； OO 编程更容易理解，因为它所操作的代码和数据是靠得很近的。为什么选择？拥抱“和”的力量；两者都做！

【讨论】：

【解决方案2】：

你可以用这种方式编写工作程序，但这不是惯用的。如果你想在一个团队中工作，我会尽量控制它。如果没有其他人在阅读您的代码，那就发疯吧。

【讨论】：

同意。我认为编写看起来像 F# 程序的 C# 程序是错误的，反之亦然。您应该发挥每种语言和框架的优势，而不是试图将它们融入从其他语言或框架继承的模型中。如果您真的对 F#/Scala 编程模型感兴趣，请使用 F# 或 Scala 编程:-)。

【解决方案3】：

由于某种原因，当我阅读您的问题时，我想到了这句话：

您可以用任何语言编写 Fortran。

如果 C# 的意图是纯粹的函数式，static 将是不必要的，因为默认情况下一切都是静态的。如果您严格遵循 OOP 实践和 SOLID 原则，那么您的代码将有效地发挥作用（我知道某处有关于此的引用），因此您最终会得到两全其美的结果。

我会在多用户项目中遏制它的原因是它不是典型的 C#（它实际上是带有手铐的 C#）。你只需要一个人来打破规则并声明一个静态可变属性，一切都将一去不复返。

【讨论】：

【解决方案4】：

不完全。我确实喜欢我的扩展方法和 Linq，但是应该以 OO 方式使用 OO 语言。此外，这对 CPU 来说都是必不可少的，在此之上还有好几层。

【讨论】：

【解决方案5】：

好问题。

我认为答案取决于您的代码所做的上下文，以及其中有多少是静态的。

自从我现在对接口进行大量编程并将一些方法标记为“受保护的虚拟”而不是“静态”用于单元测试的提取和覆盖模式等情况以来，我的代码看到的静态案例越来越少。不过，这并不是说您不能从调用静态方法。

【讨论】：

【解决方案6】：

当你编写 OOP 时，有很多理由应该抑制这种本能。

对象状态和行为；

静态类和方法需要参数，你应该确定哪些参数会传递给静态方法。但是如果与状态相关的方法，则类会自行管理。

我认为只有这个理由足以遏制静态修饰符。

出于明确的原因，我们应该听 Liskov 夫人的意见。 here

【讨论】：

LSP 与静态辅助方法有什么关系？
如果我在助手中看到任何方法被静态修改而没有“this”参数，我会感到惊讶。静态助手方法并不是真正的“静态”，它只是由“静态”修改。必须有人写一些静态方法，而类体中最好的地方（C#中没有选择）方法必须定义在一个类中。
@Ben - 一个静态方法不能被替代，一个替代另一个，没有依赖者知道差异。这违反了 SOLID 的几个相互关联的原则，包括 LSP。如果您的程序是高度静态的，那么它是紧密耦合的，与以任何其他方式组织时相比，即使作为单例，您也需要在更多地方更改代码。
@Nuni：准备好惊喜吧。 @KeithS：一个类的成员与同一个类的其他成员紧密耦合也不错。
@Ben Voigt：假设 SList : List 并向 SList 添加几行方法代码。有一天你需要另一个 FList ： SList 很有用。不？好的。准备另一个 Flist : List 但我想使用 SList 中的一些方法我不想重复一些方法。我应该使用多重继承吗？不！ C# 进行更改以添加一些具有静态扩展的方法。这是使用静态方法的“真正”原因之一。当然，当 C# 支持多重继承时，我会感到很惊讶。我想知道我们将如何做许多静态扩展许多程序集和命名空间。Khaos？