C# 什么时候去上静态课程？

每当我为某个问题编写解决方案时，我倾向于要么使用大量静态类，要么根本不使用。例如，在最近的一个项目中，我必须通过许多环发送一个包含string/bool/datetime数据的类，唯一不是静态的是这个数据保存类。其他一切（3个相当大的类，具有不同的处理职责）都是静态的

我想我在这里要求的是一些关于何时（以及为什么）应该避免在这些“进程X，输出Y”情况下使用静态类的输入。只要它们能工作，就可以一直使用它们吗？还是我在可伸缩性、插件支持等方面自讨苦吃

---

我希望这是一个可以在这里问的问题。我并不是要讨论静态类是否“更好”，只是要说明我应该避免使用它们的时间。

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

我编写的大部分代码：

• 使用依赖注入/IoC
• 并且需要可模拟/可测试

所以我几乎什么都用对象

我仍然会对以下内容使用静态：

• 扩展方法
• 常数
• 辅助程序/实用程序方法（预扩展方法）
• 算子方法

---

这两个问题仍然有点相同。我主要关心的是静态类的继承性和可访问性
当使用静态类（在最坏的情况下为public）时，每个人都可以访问您的进程和函数。大多数情况下，这不是你想要的。对于某些对象来说，访问函数并进行一些修改太容易了。因此，依赖注入很好用。（在参数中传递要修改的对象，在本例中是您的

处理对象

）
为了防止其他人操纵您的

进程对象

，为什么不尝试使用某种单例模式（甚至是前单例模式），这样实际上就有一个真正的对象可以与之对话？如果需要修改某些内容，可以将对象传递到函数的参数中。然后，您就可以有一个管理器来保存您的

流程对象

。其他人不应该接近目标

---

静态类也很难继承。重写静态方法似乎有点奇怪。因此，如果您确定流程不是唯一的流程，并且您将创建一些更具体的流程，那么也应该避免使用静态类。
如果只有一个方法，我建议您使用静态方法。在这种情况下，创建类的实例几乎没有意义
如果希望字段的行为有点像

全局变量

，则可以使用静态属性。这是一种与

单例模式匹配的设计模式

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

---

对于rest来说，与我的工作对象相关的一切都是一条路要走（显然有一些小的例外）
广泛使用静力学就像把你的应用程序放到具体的东西中一样。除了非常特殊的情况，例如非常通用的实用程序/辅助程序方法，应该避免使用它们。djeeg在之前的回答中给出了一个很好的列表。
我看到的使用静态类的主要问题是依赖关系是硬连接的。如果类A需要使用来自类B的特性，它必须明确地知道它，这会导致紧密耦合
虽然这并不总是一个问题，但随着代码的增长，您可能会发现更难改变程序的行为以适应新的需求。例如，如果您想使程序的行为可配置，这将是困难的，因为这将需要在代码中明确的if/switch。否则，您可以简单地使类依赖于接口和交换实现

---

简而言之，您正在阻止自己使用众所周知的设计模式，这些模式是解决您可能遇到的问题的良好解决方案。
我通常会尝试避免在类中使用静态方法。如果我需要全局访问一些数据，我至少会将一个类包装在一个单例中。对于较大的项目，我建议使用控制反转容器以单例方式实例化和注入“全局”实例。
我想到的第一件事是，为什么不能让“数据持有类”负责对其数据进行任何必要的操作？这将避免需要一堆额外的静态类，并减少不必要的耦合。这里已经详细介绍了这一点，请尝试以下链接作为开始：&VS 2008中的代码分析工具将始终建议如果没有或使用任何实例数据，则方法/类应为静态的。这是一个好的实践吗？将静态数据操作方法添加到数据保持类中？总的来说，这可能是一个好主意——不过，这种数据处理的一些方面，例如，将类转换为它的HTML表示形式，这感觉有点过于具体，无法放入同一个类中。但也许我只是看错了。编辑：谢谢你的回答，所有的答案都很好。确实，HTML编写器不应该在数据保存类中。因为它不操纵数据，所以它不应该在那里。