c# - 关于将公共(public)实用程序类静态化的意见

Question

我昨天和今天读到的一些内容:

• (SO) Should you avoid static classes?
• (SO) When to Use Static Classes in C# - Mark S. Rasmussen 发表了很好的评论 here
• Singleton vs Static - 来自这里的好报价:

  These differences are extremely subtle but they do impact how resilient the system will hold up after years of subtle changes, new features, enhancements, etc. Most developers dislike system maintenance and I feel the biggest reason is because systems aren't really designed to be maintained. By incorporating the "singleton" pattern above, I've abstracted object creation and typing away from my core business logic which is critical to long-term maintenance.

• Singleton Considered Stupid
• (SO) Class with single method — best approach? - 再次引用 Mark S. Rasmussen 的话:

  Demanding consumers to create an instance of classes for no reason; True utility classes that do not pose any risk to bloat are excellent cases for static methods - System.Convert as an example. If your project is a one-off with no requirements for future maintenance, the overall architecture really isn't very important - static or non static, doesn't really matter - development speed does, however.

• (SO) Making Methods All Static in Class - 速度现在对我来说不是问题，当多个客户端从网站和(可能但不太可能)来自管理应用程序的多个客户端调用时，代码必须*正确*有效。

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

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

• 复制文件:
  • 复制文件
  • 解密并复制文件
• XML 设置文件:
  • GetSpecificXMLValue(查询 XML 设置文件的值)
  • 设置特定的 XML 值
  • 删除特定 XML 值
• 创建目录
• 获取字符串形式的时间戳(`return DateTime.Now.ToString("yyyyMMddHHmmss");`)
• 传递参​​数的各种字符串函数
• 写出日志文件。
• 检查传递的字符串参数是否仅包含白名单中的元素(白名单是在构造函数中分配值的“只读”私有(private)列表。)

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

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这些词时，我会立即想到代码味道。没有什么比命名没有实际意义的类更容易的了，只是在里面埋下巨大的管道代码。通常这种情况发生在开发人员太受过程式编程的影响时。

回答问题——我通常不喜欢静态的东西(并发问题、更难的实例生命周期管理等)。静态有用的情况很少见，我相信这不是其中之一。

---

如果“想要的静态辅助方法”适合，请编写扩展方法。如果没有，那么它应该在单独的服务中或在某些东西的基类中(这取决于上下文)。

---

So a class that manages things shouldn't be called SomethingManager? I disagree in that specific case

有些情况下它可能是合适的。但正如我所见 - 'XManager' 只是告诉你这个 'Manager' 类与类 'X' 一起工作并且 'manages' 任何 'managing' 应该意味着什么。 helper 帮忙做某事。究竟是什么？谁知道 - 必须检查代码。 “共同”更加模糊。在这样的类/命名空间/项目中看到了各种东西(数据访问、安全和 UI 相关的东西与业务域逻辑捆绑在一起)。

---

Hmmm... so maybe namespace Us.Common { public (static?) class Strings {} public (static?) class Files {} public (static?) class Settings {} } Opinions on this architecture change? Once again, I'm interested in maintainability and usability please.

您可能会发现有用的 this post .根据它 - 在您的案例中是逻辑内聚。