静态类是我能用时的良好实践吗？

Question

让我更加明确一些。在我的winforms项目中，我正在创建用于管理/创建程序的每个部分的类。我这样做是为了更好地控制我的代码。例如，我有一个名为gridManager的类来管理我的DataGridView控件。我在其中设置所有属性、颜色等，并且还有更改这些设置的方法（例如，changeBackgroundColor()等）。

我还为splitContainer中的每个Panel编写了这种类型的类。在这些类中，我初始化了每个作为panel子级的控件，将它们添加到该panel中并设置所有属性等。

我写这些内容是为了让您更好地了解这些类的目的。

现在我的问题是：将这些类设为静态类是否是一个好的做法？其中包含的所有控件和方法都是静态的吗？

起初，它们不是静态的，但当我想从选项窗体调用更改颜色等方法时，我必须要么将MainForm作为参数传递，要么像这样操作：

(Application.OpenForm[0] as MainForm).gridManager.changeColor();

静态版本会使得操作变得更加容易，但是我在想这是否是一件好事。 哎呀，有很多需要解释的地方，希望我的英语不太好不会让它更难理解。 :)

- Brazol

Answer 1

全局可变状态通常是一个不好的想法。

静态方法/类适用于简单的无副作用函数。 Math和Enumerable是很好的例子。

然而，你想要控件在静态字段中。这些是可变状态，因此应该避免使用。例如，如果您明天想要拥有两个表单实例，则需要两个管理器类实例。但它是静态的，现在需要重写使用它的所有代码。

- CodesInChaos

Answer 2

就像任何事物一样，静态类也有其优势和不足之处。我能想到的两个“负面”方面是：

1. 您无法从静态类继承
2. 您无法（轻松地）模拟静态类进行测试

但是在您的情况下，似乎您不会从这些类中继承任何内容，因此在这种情况下使用静态类应该没有问题。

编辑 这是假设您正在做控件工厂之类的操作。
例如： var grid = GridManager.CreateGrid(options);

如果您正在执行以下操作：

var data = GridManager.GetDataFromGrid(myGrid)

我可能会重新考虑。

- taylonr

Answer 3

静态类有它们的应用场景，但这个场景可能不是其中之一，除非它是一个快速而简单的应用程序。如果你想在代码周围进行自动化测试，那么如果被测试的代码使用静态类来设置首选项，那么这几乎是不可能的。

最好使用 单例模式。这样，在自动化测试期间可以替换实现。

- agent-j

---

如果可能的话，我甚至会避免使用标准的单例模式。在我看来，最好将其注册为 DI 容器中的单例。这样，您就不会将某些东西是单例的假设固化到消费代码中。 - CodesInChaos

Answer 4

最好使用与该网格对象相关联的普通类来完成。如果您需要另一个网格对象，则可能需要实例化另一个实例。控制器不是静态类的最佳选择。

- Cem Kalyoncu

Answer 5

静态类确实有它们的用处，但我认为每次都使用它们是一个不好的建议。

OOP的整个概念是围绕实例构建的，因此大多数情况下应该使用非静态类。原因是什么？主要是灵活性。您可以拥有两个实例，它们以稍微不同的方式执行相同的操作，这取决于它们的内部状态。您可以拥有相同概念的更多实现，并且可以轻松地切换它们。您可以使用诸如Inversion of Control容器之类的东西。等等。

- svick

Answer 6

这不是好的或坏的做法，而是某些任务的常见模式。

一般来说，您会使用静态方法来处理与类类型相关但不依赖于任何实例数据的功能，经典用途之一是像工厂类型方法那样返回所附加到的类的已初始化实例。

public SomeClass = SomeClass.CreateWithSomeInit(parms);

- Tim Jarvis