什么时候上静态课程？答案

【问题标题】：When to go for static classes?什么时候上静态课程？
【发布时间】：2011-01-12 10:39:44
【问题描述】：

每当我为某事编写解决方案时，我倾向于要么使用大量静态类，要么根本不使用。例如，在最近的一个项目中，我必须通过一些箍发送一个带有一些字符串/布尔/日期时间数据的类，唯一不是静态的就是这个数据保存类。其他所有内容（3 个具有不同处理职责的相当大的类）都是静态的。

我认为我在这里要求的是一些关于何时（以及为什么）我应该避免对这些“进程 X，输出 Y”情况使用静态类的输入。只要它们正常工作就可以一直使用它们，还是我在可扩展性、插件支持等方面自责？

我希望这是一个可以在这里问的问题。我不是在要求关于静态类是否“更好”的论点 - 只是输入我应该何时避免使用它们。

【问题讨论】：

我首先想到的是为什么不能让“数据持有类”负责对其数据进行任何必要的操作？这将避免需要一堆额外的静态类，并减少不必要的耦合。
这已在此处广泛介绍，请尝试以下链接：Uses for static generic classes? & Extension Methods vs Static Utility Class
VS 2008 中的代码分析工具将始终建议方法/类如果没有或不使用任何实例数据，则应该是静态的。这是好的做法吗？
在数据持有类中添加静态数据操作方法？一般来说，这可能是一个好主意——但是，其中一些数据处理是例如将类转换为它的 HTML 表示形式，这感觉有点过于具体，无法放入同一个类中。但也许我只是以错误的方式看待它。编辑：感谢您的回答，一切都很好。
确实，HTML 编写器不应该属于数据持有类。因为它不操纵数据，所以它不应该存在。

标签： c# .net

【解决方案1】：

我写的大部分代码：

所以我几乎所有事情都使用对象。

我仍然在以下方面使用静态：

【讨论】：

【解决方案2】：

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

当使用静态类（最坏的情况下是公共的）时，每个人都可以访问您的进程和函数。大多数时候这不是你想要的。某些对象太容易获得您的功能并进行一些修改。因此，依赖注入很好用。（在参数中传递您要修改的对象，在本例中为您的process-object）。

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

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

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

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

您可以拥有静态属性，以防您希望某个字段的行为有点像global variable。这是一个匹配Singleton pattern的设计模式

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

其余与我的工作对象相关的一切都是要走的路（显然有小例外）

【讨论】：

【解决方案5】：

广泛使用静力学就像将您的应用程序具体化。应该避免使用它们，除非是非常特殊的情况，例如非常通用的实用程序/辅助方法。 djeeg 在之前的回答中发布了一个不错的列表。

【讨论】：

【解决方案6】：

正如您所描述的，我看到使用静态类的主要问题是依赖关系是硬连线的。如果 A 类需要使用 B 类的特性，它必须明确知道它，这会导致紧密耦合。

虽然这并不总是一个问题，但随着代码的增长，您可能会发现更改程序的行为以适应新的需求变得更加困难。例如，如果您想让程序的行为可配置，这将很困难，因为这需要在代码中显式地 if / switch。否则，您可以简单地使类依赖于接口并交换实现。

简而言之，您正在阻止自己使用众所周知的设计模式来解决您可能遇到的问题。

【讨论】：

【解决方案7】：

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

【讨论】：