用于misc功能的静态类的理想类名

Question

什么是我的静态类的理想类名，它有一些静态方法来处理备用的常规/常用功能，在C＃中保存最近的项目etxc ..（Infact Misc items）。我想将Manager作为类名的后缀（例如：SaleManager（用于处理与销售相关的功能），ContatManager（用于处理与联系人相关的功能）

Answer 1

RefactorMeManager。

Answer 2

以下是一些执行这些类型操作的.NET Framework类：

• 系统环境
• System.Math
• 有System.IO.File
• System.IO.Directory
• System.IO.Path
• System.Runtime.InteropServices.Marshal

如您所见，例程按主题分组到类中，并且没有类附加“Helper”或“Utilities”。以下是我制作的一些类，它们可以执行以下某些类型的操作：

• SymbolicMath（类似于Math类，但用于处理符号数学表达式）
• BigIntegerMath（使用System.Numerics.BigInteger类型的大整数运算库 - primality证明，因子分解和其他一些东西）

Answer 3

事实证明，“效用”是有争议的，而“数学”则不是。因此，似乎该名称应该建议静态类中方法的整体功能。

Answer 4

我的一般感觉是，不应该有这样一般的课程。特别是电子邮件很可能扩展到不仅仅是一个SendEmail（）方法，坦率地说new Email({to, subject, body}).Send()更有意义。

Answer 5

如果你有一个具有大量静态方法的Utility（或UtilityManager）类，那确实是一个反模式，应该重构。

然而，有些东西就是 - 实用程序，并且不应该避免将它们放在单独的 Utilities 类（我个人最喜欢的）中。是的，这为各种各样丑陋的场景打开了大门，一个人必须握住缰绳，或者任何东西，一切都会在那里结束，是的，有必要向自己的班级“推广”方法（通常是XXXHelper）如果需要，但是，尽管如此，我发现Utilities类是一个有用的结构，而不是反模式本身。模式毕竟是一种推荐，它们不是宗教信仰：）

作为这种类的后缀的管理器令人困惑，因为该类实际上并没有管理任何东西。

Answer 6

万岁internal static class Utils。

Answer 7

工具
实用工具 扩展（如果你只在那里放置扩展方法（C＃））

Answer 8

UtilityManager ..？

Answer 9

有very good reasons没有做那种事情。它被认为是一种反模式。

Answer 10

即使对于静态类（顺便说一句：我更喜欢XxxHelper后缀），我仍然坚持范式“Separation of Concerns”并且不会在一个类中混合使用不同的实用程序。