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

Question

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

• (SO)你应该避免静态课吗？
• (SO)何时在C#中使用静态类 - Mark S. Rasmussen 在这里做了一个很好的评论
• Singleton vs Static - 来自这里的好评:

  这些差异非常微妙,但它们确实会影响系统在经过多年微妙变化,新功能,增强功能等后的弹性.大多数开发人员不喜欢系统维护,我觉得最大的原因是因为系统并非真正设计为保持.通过结合上面的"单例"模式,我抽象了对象的创建和打字,远离我的核心业务逻辑,这对于长期维护至关重要.

• Singleton被认为是愚蠢的
• (SO)单一方法的类 - 最好的方法？ - 再一次,Mark S. Rasmussen的一句话:

  要求消费者无缘无故地创建一个类实例; 对静态方法没有任何风险的真实实用程序类是静态方法的优秀案例 - 以System.Convert为例.如果您的项目是一次性的,对未来的维护没有要求,那么整体架构确实不是很重要 - 静态或非静态,并不重要 - 然而,开发速度确实如此.

• (SO)制作方法所有类中的静态 - 速度现在对我来说不是问题,当来自网站的多个客户端和(可能但不太可能)来自管理应用程序的多个客户端调用时,代码必须正常*正常工作*.

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

这个类处理的事情(不是真正的方法名称或签名):

• 复制文件:
  • 拷贝文件
  • 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 在这里描述的单例？

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 {}}关于这个架构的观点有变化吗？再一次,我对可维护性和可用性感兴趣.

你可能会觉得这篇文章很有用.根据它 - 它Logical cohesion在你的情况下.

Answer 2

这里的标准是国家.如果您的类只是独立函数的容器(即CopyFile,GetTimeStamp),则静态类是最合乎逻辑的方法.看System.Math课.

但是你的类有一个构造函数,我认为它拥有一些状态(config/log文件的名称).这需要一个单身人士.

查看功能列表,我认为您应该将其重构为几个类.有些人可以(而且应该)是静态的.对需要状态的部件使用Singleton,如Logging and Configuration等.

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