关于C#：关于使公共实用程序类静态化的意见

Opinion on Making a Common Utility Class Static

我昨天和今天读到的关于这个的一些内容：

(那么)应该避免静态类吗？
(所以)什么时候使用C-Mark S.Rasmussen中的静态类在这里做了一个很好的评论
单件vs静态-这里的引用很好：

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.
辛格尔顿被认为是愚蠢的
(那么)用单一方法分类-最佳方法？-再次引用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.
(所以)对于我来说，让方法在类速度中都是静态的并不是一个问题，当多个客户从网站和(可能，但不太可能)管理应用程序调用多个客户机时，代码必须正确地工作。

我们现在正忙于重写我们的主要应用程序，解决方案中的一个项目是"common"，它包含一个类"clscommon"。这个类没有属性，只有一个私有方法，作为构造函数中的唯一一行调用，然后只调用公共方法。

此类处理诸如(不是真正的方法名或签名)之类的事情：

复制文件：
- 复制文件
- 解密和复制文件
XML设置文件：
- getspecificXMLvalue(查询XML设置文件中的值)
- 设置特定XML值
- 删除特定XML值
正在创建目录
以字符串形式获取时间戳(`return datetime.now.toString("YYYYMMDDHHMMSS")；`)
传递参数的各种字符串函数
正在写入日志文件。
检查传递的字符串参数是否只包含白名单中的元素(白名单是在构造函数中分配了值的"readonly"私有列表)。

目前，解决方案中的所有其他项目都引用了这个项目，并且它们提供了对该类的访问：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

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所说的单身？

当我听到单词Common，Manager，Helper时，我立刻想到了代码气味。没有什么比命名类w/o的实际意义更容易的了，只需在内部挖掘巨大的管道代码。通常，当开发人员受到过程编程的影响太大时，就会发生这种情况。

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

如果"wannabe static helper method"适合，则写入扩展方法。如果没有，那么它应该在单独的服务或某个东西的基类中(这取决于上下文)。

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

有些情况下可能是合适的。但正如我所看到的，"x manager"只是告诉你这个"manager"类与"x"类一起工作，并且"manages"应该是什么意思。帮助者帮助某事。到底是什么？谁知道--要查一下代码。"共同"甚至更模糊。在这样的类/命名空间/项目(数据访问、安全和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.

你可能会发现这篇文章很有用。根据它，你的案子是Logical cohesion。