C＃模式可以清晰地处理“自由功能”，避免使用Helper风格的“实用程序包”静态类

我最近正在查看一些浮动的Helper风格的“实用程序包”静态类，这些静态类围绕我使用的一些大型C＃代码库进行浮动，基本上类似于以下非常简短的代码段：

// Helpers.cs

public static class Helpers
{
    public static void DoSomething() {}
    public static void DoSomethingElse() {}
}

我审查过的具体方法是

• 彼此之间几乎没有关系
• 没有明确的状态在调用之间持续存在，
• 小，和
• 每一种都由各种不相关的类型消耗。

编辑：上面的内容并非旨在列出所指控的问题。这是我正在审查的特定方法的共同特征的列表。帮助答案提供更多相关解决方案的上下文。

仅针对此问题，我将把这种方法称为GLUM（通用轻量级实用程序方法）。部分地意在“消极”的负面含义。抱歉，这是愚蠢的双关语。

即使撇开我自己对GLUM的默认怀疑态度，我也不喜欢以下内容：

• 静态类仅用作命名空间。
• 静态类标识符基本上是没有意义的。
• 添加新的GLUM时，要么（a）毫无理由地触摸此“ bag”类，要么（b）创建一个新的“ bag”类（这本身通常不成问题；糟糕的是，新的静态类通常只会重复不相关性问题，但方法更少。
• 元的命名无疑也是可怕的，非标准的，通常内部不一致，无论是Helpers，Utilities或什么的。

什么是重构的合理好简单的模式，最好解决上述问题，并且最好轻触一下？

我可能应该强调：我正在处理的所有方法都是成对的彼此无关。似乎没有一种合理的方法可以将它们分解为更细粒度但仍为多成员的静态类方法包。

我认为您有两个彼此密切相关的问题。

• 静态类包含逻辑上不相关的功能
• 静态类的名称不提供有关所包含函数的含义/上下文的有用信息。

通过仅将逻辑相关的方法组合到一个静态类中，并将其他方法移动到其自己的静态类中，可以解决这些问题。根据您的问题领域，您和您的团队应该决定将什么方法用于将方法分为相关的静态类的标准。

问题和可能的解决方案

方法大多彼此无关 - 问题。 将一个静态类下的相关方法组合在一起，并将不相关的方法移到它们自己的静态类中。

方法没有在调用之间持久保留的显式状态 -这不是问题。 无状态方法是功能，而不是错误。无论如何，静态状态都很难测试，并且仅在需要在方法调用之间维护状态时才应使用静态状态，但是有更好的方法来做到这一点，例如状态机和yield关键字。

方法很小 - 没问题。-方法应该小。

每个方法都由各种不相关的类型使用 -这不是问题。您已经创建了一种通用方法，可以在许多不相关的地方重复使用该方法。

静态类仅用作命名空间 - 没问题。这就是使用静态方法的方式。如果这种调用方法的样式困扰您，请尝试使用扩展方法或using static声明。

静态类标识符基本上是没有意义的 - 问题。这是没有意义的，因为开发人员正在将不相关的方法放入其中。将不相关的方法放入其自己的静态类中，并为其指定特定且易于理解的名称。

当添加新的GLUM时，要么（a）触及了这个“袋子”类（SRP悲伤），如果您遵循一个逻辑类中应该只包含逻辑相关方法的想法，这不是问题。 SRP这里不违反，因为原则应适用于类或方法。静态类的单一职责意味着为一个一般的“想法”包含不同的方法。这个想法可以是功能，转换，迭代（LINQ），数据规范化或验证...

或更不频繁地（b）创建一个新的“袋子”类（更多袋子） -这不是问题。 类/静态类/函数-是我们的（开发人员）工具，用于设计软件。您的团队在使用课程方面有一些限制吗？“更多行李”的最大限额是多少？编程全都与上下文有关，如果要在您的特定上下文中获得解决方案，您最终会得到200个静态类，这些类可以理解地命名，并以逻辑层次结构逻辑地放置在名称空间/文件夹中-这不是问题。

元的命名无疑也是可怕的，非标准的，通常内部不一致，无论是助手，公用设施，或任何 - 问题。 提供描述预期行为的更好的名称。仅将相关的方法放在一个类中，这有助于更好地命名。

只需遵循这样的约定：在C＃中，静态类就像名称空间一样使用。命名空间获得好名，这些类也应获得好名。using staticC＃6的功能也使生活更加轻松。

诸如此类的臭名昭著的类Helpers信号表明，如果可能，应将这些方法拆分为命名更好的静态类，但是您强调的假设之一是，您要处理的方法是“成对无关的”，这意味着拆分为每个现有方法一个新的静态类。如果可能的话，那可能很好

• 新的静态类有好名字，
• 您认为它实际上使您的项目的可维护性受益。

作为一个人为的示例，Helpers.LoadImage可能会变成FileSystemInteractions.LoadImage。

不过，您最终可能会遇到静态类方法包。发生这种情况的一些方法：

• 也许只有一些（或没有）原始方法为其新类命名。
• 也许以后新类会演变为包含其他相关方法。
• 也许原来的班级名称没有臭味，实际上还可以。

重要的是要记住，这些静态类方法包在真正的C＃代码库中并不少见。拥有几个小孩子可能不是病态的。

如果您真的在每个文件中都拥有类似“免费功能”的方法（如果您诚实地认为它确实有益于项目的可维护性，那么这很好并且值得），则可以考虑使用这样的静态类而不是静态类部分类，采用类似于要使用名称空间的静态类名称，然后通过进行使用using static。例如：

Program.cs

namespace ConsoleApp1
{
    using static Foo;
    using static Flob;

    class Program
    {
        static void Main(string[] args)
        {
            Bar();
            Baz();
            Wibble();
            Wobble();
        }
    }
}

Foo / Bar.cs

namespace ConsoleApp1
{
    static partial class Foo
    {
        public static void Bar() { }
    }
}

Foo / Baz.cs

namespace ConsoleApp1
{
    static partial class Foo
    {
        public static void Baz() { }
    }
}

Flob / Wibble.cs

namespace ConsoleApp1
{
    static partial class Flob
    {
        public static void Wibble() { }
    }
}

Flob / Wobble.cs

namespace ConsoleApp1
{
    static partial class Flob
    {
        public static void Wobble() { }
    }
}

通常，您不应该拥有或不需要任何“通用实用程序方法”。在您的业务逻辑中。再看一眼，放在合适的地方。

如果您正在编写数学库之类的东西，那么尽管我通常讨厌它们，我还是建议您使用扩展方法。

您可以使用扩展方法将功能添加到标准数据类型上。

例如，假设我有一个通用函数MySort（）而不是Helpers.MySort或添加了一个新的ListOfMyThings.MySort我可以将其添加到IEnumerable