logo标签列表

何时使用静态类？

c#.net
4
每当我编写解决方案时，我倾向于要么使用大量的静态类，要么根本不使用。例如，在最近的一个项目中，我必须通过许多步骤发送一个带有一些字符串/布尔/日期时间数据的类，唯一不是静态的是这个数据持有类。其他所有内容（3个非常重要的具有不同处理职责的类）都是静态的。
我想我在这里所问的是关于何时（以及为什么）我应该避免在这些“处理X、输出Y”情况下使用静态类的建议。只要它们工作得好，总是可以使用它们吗？还是说，关于可扩展性、插件支持等问题，我会给自己惹上麻烦？
我希望这是一个可以在这里提出的问题。我不是在争论静态类是否“更好”，只是想知道何时应避免使用它们的建议。
1
我首先想到的是，为什么不能让“数据持有类”负责对其数据进行必要的操作呢？这样可以避免需要大量额外的静态类，并减少不必要的耦合。 - Cody Gray
2
这个问题已经在这里详细讨论过了，你可以从以下链接开始查看：静态泛型类的用途？ 和 扩展方法 vs 静态工具类。 - slugster
1
在VS 2008中的代码分析工具将始终建议将没有或不使用任何实例数据的方法/类设置为静态。这是一个好的做法吗？ - Polyfun
将静态数据操作方法添加到数据持有类中？总的来说，这可能是个好主意 - 但是其中一些数据处理例如将类转换为其HTML表示形式，感觉有点太具体了，不适合放在同一个类中。但也许我只是从错误的角度看待它。 编辑：感谢所有的回答，都很好。 - Anders Arpi
HTML编写器不应该在数据持有类中。因为它不操作数据，所以不应该在那里。 - Marnix
7个回答
4

我写的大部分代码:

  • 使用依赖注入/控制反转
  • 需要进行模拟/测试

所以我几乎为所有东西都使用对象。

我仍然会使用静态方法来处理以下内容:

  • 扩展方法
  • 常量
  • 帮助/实用方法（扩展方法之前）
  • 操作方法
2

这两个问题仍然有些相同。我对静态类的主要关注点是继承和可访问性。

使用静态类（在最坏的情况下是公共的）时，每个人都能够访问您的过程和函数。这通常不是您想要的。某些对象很容易获得您的函数并进行一些修改。因此，依赖注入很好用。（将要修改的对象传递给参数，在这种情况下是您的process-object）。

为了防止其他人操纵您的process-object，为什么不尝试使用某种单例模式（甚至是前单例模式），以便实际上有一个真正的对象可以交谈？如果需要修改某些内容，您可以将对象传递到函数的参数中。然后，您只需拥有一个管理器来持有您的process-object。其他人不应该接触到该对象。

静态类也很难继承。覆盖静态方法似乎有点奇怪。因此，如果您确定该进程不是唯一的进程，并且您将创建一些更具体的进程，则还应避免使用静态类。

1

静态类通常用于小型数据容器和通用方法。除非必要，否则不应包含大量数据。这些类是不可扩展的。

1

如果一个方法只有一个方法，我建议您将其设置为静态方法。在这种情况下，创建类的实例几乎没有意义。

如果您想让字段像全局变量一样运行，可以使用静态属性。这是一种与单例模式相匹配的设计模式。

我使用静态属性来跟踪整个应用程序需要消耗的状态。

对于我的工作对象，除了少数例外，一切都是可行的。

1
大量使用静态变量就像把你的应用程序固定在混凝土中一样。除了非常特殊的情况（如非常通用的实用程序/辅助方法）外，应该避免使用它们。djeeg在以前的答案中发布了一个很好的列表。
1
我认为使用您所描述的静态类的主要问题在于依赖关系是硬编码的。如果A类需要使用B类的功能，它必须明确知道这一点，这会导致紧密耦合。
虽然这并不总是一个问题，但随着代码的增长，您可能会发现更难以改变程序的行为以适应新的需求。例如，如果您想使程序的行为可配置，那么将很困难，因为这将需要在代码中显式地使用if / switch。否则，您可以简单地使一个类依赖于一个接口并交换实现。
简而言之，您阻止自己使用众所周知的设计模式，这些模式是已知的良好解决方案，用于解决您可能会遇到的问题。
1

我通常尽量避免在类中使用静态方法。如果我需要全局访问某些数据，我至少会将一个类包装成单例模式。对于更大的项目，我建议使用控制反转容器以单例方式实例化和注入您的“全局”实例。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接