静态类被认为是不好的做法吗?几天前我读了一篇关于这个的文章(找不到它,抱歉),它基本上说拥有静态类(尤其是那些“帮助”类)通常是错误代码的标志。这是正确的,如果是,是什么原因?
7 回答
滥用静态类可以被认为是不好的做法。但是滥用任何语言功能也是如此。
我没有区分只有静态方法的非静态类和静态类。它们实际上是相同的,除了静态类允许编译器强制执行开发人员的意图(不实例化此类,访问其功能的方便语法等)。
正如您所说,“Helper”类的激增可能会给您带来麻烦(设计、可维护性、可读性、可发现性、其他能力......)。这里没有争论。但是你能说“帮助者”类是不合适的吗?我对此表示怀疑。
事实上,负责任地使用静态类可以为您的代码带来巨大的好处:
Enumerable
静态类提供了一组我们大多数人都喜欢的扩展方法。它们是一组逻辑功能/业务逻辑,与任何特定类型的实例无关。- 环境/上下文提供的服务:例如日志记录、配置(有时)
- 其他(我暂时想不到:))
所以不,一般来说,这不是坏习惯。只要明智地使用它们...
我认为一般的论点是反对在静态类中保持可变状态,并且基本上将它们用作全局变量。静态类中的静态辅助方法没有任何问题。
至于为什么全局变量不好,我敢肯定,在这里和谷歌之间,你会发现几百万个页面和关于它的博客文章。
不,这并不完全正确。
有很多函数不是特定于对象实例的,并且不需要状态。例如考虑“数学”函数。
几乎所有语言都有类似的东西:
y = Math.round(x);
所以'round'函数是静态的。如果你疯了,你可以为(C#)之类的东西争论:
class RoundFunction<T> : GeneralMathFunction<T>
{
public override T Operate (params object[] variables) {
..
}
}
但是,恕我直言,这样做会有点奇怪。
当然,有时静态函数过多是出现问题的迹象,但在合理范围内,这并不是“坏事”。
这是否意味着“使用静态类是错误的”(在这种情况下,文章不正确)或“静态类经常出现在写得不好的代码中”(在这种情况下,并不是说静态类本身不好,而是说它们有时使用不正确)
静态函数比非静态函数更有效,因为您无需创建对象实例即可使用它们或将“this”指针传递给方法调用。
使用静态类来保存全局变量是另一回事——在这种情况下,基本规则不是“静态是坏的”,而是“全局是坏的”。
以下是一些谷歌测试博客文章的链接,这些文章介绍了为什么静态方法会损害代码的可测试性,以及为什么静态方法(这是静态类的坏部分)会在组件之间引入各种可能令人惊讶的耦合和交互。
需要有一个实用程序类,其中所有方法都是静态的。在这种情况下,如果您将类设为静态,则它清楚地表明了您的意图。至少在 C# 中,静态类中不能有非静态方法。
我一直在我的代码中使用静态实用程序类来处理经常调用但实例化会很痛苦的方法。一个示例是一个简单的日志记录类,例如:
public static class Logging
{
public static UpdateAction(int id, object data)
{
SqlConnection connection = new SqlConnection("conn string from config file");
// more logic here...
}
}
现在,我从来没有让这些类和方法存储任何类型的全局状态,因为这会导致巨大的并发问题,而且通常只是糟糕的设计。
所以不要避免使用静态类,只是避免让这些静态类保持某种全局状态。