Question

昨天和今天我一直在阅读的一些内容：

(SO) Should you avoid static classes?
(SO) When to Use Static Classes in C# - Mark S. Rasmussen发表评论here
Singleton vs Static - 来自这里的好评：
这些差异非常微妙，但它们确实会影响系统在经过多年微妙变化，新功能，增强功能等后的弹性。大多数开发人员不喜欢系统维护，我觉得最大的原因是系统不是真的旨在维护。通过合并上面的“单例”模式，我抽象了对象创建和打字，远离我的核心业务逻辑，这对于长期维护至关重要。
Singleton Considered Stupid
(SO) Class with single method — best approach? - 再一次，Mark S. Rasmussen的一句话：
要求消费者无缘无故地创建类的实例;对静态方法没有任何风险的真实实用程序类是静态方法的优秀案例 - 以System.Convert为例。如果您的项目是一次性的，对未来的维护没有要求，那么整体架构确实不是很重要 - 静态或非静态，并不重要 - 但是开发速度确实如此。
(SO) Making Methods All Static in Class - 速度现在对我来说不是问题，当网站和（可能是）多个客户端调用代码时，代码必须正常工作 * PROPERLY * 但不太可能）管理员应用程序中的多个客户端

我们（我）正忙着重写我们的主要应用程序，解决方案中的一个项目是“Common”，它包含一个类“clsCommon”。这个类没有属性，一个私有方法被称为构造函数中的唯一行，然后只是公共方法。

这个类处理的事情（不是真正的方法名称或签名）：

复制文件：
- 的CopyFile
- DecryptAndCopyFile
XML设置文件：
- GetSpecificXMLValue（查询XML设置文件中的值）
- SetSpecificXMLValue
- DeleteSpecificXMLValue
创建目录
将时间戳记作为字符串（`return DateTime.Now.ToString（“yyyyMMddHHmmss”）;`）
传递参数的各种字符串函数
写出日志文件。
检查传递的字符串参数是否只包含白名单中的元素（白名单是`readonly`私有列表，在构造函数中赋值。）

目前，解决方案中的所有其他项目都引用了此项目，并通过以下方式提供对该类的访问：

namespace Us.OtherProjects
{
   public class clsCommon : Us.Common.clsCommon
   {}
}

namespace Us.OtherProjects
{
   public static class clsMain
   {
         public static clsCommon CommonClsClassReferenceForGlobalUsage = new clsCommon();
         .
         .
         .
   }
}

namespace Us.OtherProjects
{
   public class clsOtherClass
   {
      .
      .
      .
         private void someMethod()
         {
            string something = clsMain.CommonClsClassReferenceForGlobalUsage.Foo();
         }
      .
      .
      .
   }
}

您对将此类设为静态类或Jon Skeet here所描述的单例有什么看法？

Answer 1

当我听到单词Common，Manager，Helper时，我会立即想到代码气味。没有什么比命名类没有实际意义更容易，只是在里面挖出巨大的管道代码。通常，当开发人员过程受到程序编程的影响时，就会发生这种情况。

回答问题 - 我一般不喜欢静态的东西（并发问题，更难的实例生命周期管理等）。在极少数情况下静态是有用的，我相信这不是其中之一。

如果'wannabe static helper method'适合，请编写扩展方法。如果没有，那么它应该在单独的服务或基类中（取决于上下文）。

所以管理事物的类不应该被称为SomethingManager？我不同意这个具体案例

有些情况可能是合适的。但是正如我所看到的那样 - 'XManager'只是告诉你这个'经理'课程与'X'课程一起工作，并且'管理'什么'管理'应该是什么意思。帮手有所帮助。到底是什么？谁知道 - 必须检查代码。 “共同”更加模糊。在这样的类/命名空间/项目中看到了各种各样的东西（数据访问，安全性和UI相关的东西与业务领域逻辑捆绑在一起）。

嗯......所以也许名称空间Us.Common {public（static？）class Strings {} public（static？）class Files {} public（static？）class Settings {}}关于这种架构的观点有变化吗？再一次，我对可维护性和可用性感兴趣。

您可能会发现有用的this post。根据它 - 在你的情况下是Logical cohesion。

Answer 2

此处的标准是州。如果您的类只是独立函数的容器（即CopyFile，GetTimeStamp），则静态类是最合乎逻辑的方法。请参阅System.Math课程。

但是你的类有一个构造函数，我认为它有一些状态（config / log文件的名称）。这需要一个单身人士。

查看功能列表，我认为你应该将它重构为几个类。有些人可以（而且应该）是静态的。对需要状态的部分使用Singleton，如Logging and Configuration等。

我在这里看到的主要设计问题是有一个类可以进行日志记录，配置，格式化以及其他一些东西。

关于制作通用实用类静态的意见

2 个答案: