实用程序类和方法的命名约定和结构


Naming convention and structure for utility classes and methods

您对如何组织和命名实用程序类有什么意见吗？

每当我遇到一些代码重复，可能只是几行代码，我就把它们移到实用程序类中。

过了一段时间，我会得到很多小的静态类，通常只使用一个方法，我通常将它放在一个utility名称空间中，该名称空间会因类而膨胀。

实例：

1
2
3
4
5
ParseCommaSeparatedIntegersFromString( string )
CreateCommaSeparatedStringFromIntegers( int[] )
CleanHtmlTags( string )
GetListOfIdsFromCollectionOfX( CollectionX )
CompressByteData( byte[] )

通常，命名约定告诉您将类命名为名词。我经常会遇到很多类，比如HtmlHelper、CompressHelper，但它们并不是很有用。我还尝试过非常具体的方法，比如HtmlTagCleaner，通常每个实用方法都有一个类。

您对如何命名和分组这些助手方法有什么想法吗？

相关讨论

我相信有一个连续的复杂性，因此相应的组织。示例如下，根据项目和实用程序的复杂性进行选择，并适应其他约束：

  • 一个类(称为helper)，有几个方法
  • 一个包(称为helper)，有几个类(称为xxxhelper)，每个类有几个方法。或者，如果适合的话，可以将类拆分为几个非帮助程序包。
  • 一个项目(称为助手)，有几个包(称为xxx)，每个包都有…或者，如果适合的话，可以将包拆分为几个非帮助程序包。
  • 几个助手项目(按层、按使用中的库或其他方式拆分)

    • 在每个分组级别(包、类)：

    • 含义的共同部分是分组名称的名称
    • 内部代码不再需要这样的含义(因此它们的名称更短、更集中，并且不需要缩写，它使用全名)。

    对于项目，我通常在超级包名称中重复相同的含义。虽然在理论上不是我喜欢的选择，但在我的IDE(Eclipse)中没有看到从哪个项目导入类，所以我需要重复这些信息。该项目实际上仅用于：

    • 一个运输单位：一些可交付成果或产品将有JAR，那些不需要它的将不会)。
    • 表示依赖性：例如，一个业务项目不依赖于Web层的帮助者；在表示了项目依赖性之后，我们在明显的复杂性方面做了改进，这对我们有好处；或者发现了这样的依赖性，我们知道有问题，并开始调查…；此外，通过减少依赖关系，我们可以加速编译和构建……
    • 为了对代码进行分类，为了更快地找到它：只有当代码很大时，我才谈到项目中的数千个类。

    Please note that all the above applies to dynamic methods as well, not only static ones.
    It's actually our good practices for all our code.

    Now that I tried to answer your question (although in a broad way), let me add another thought
    (I know you didn't ask for that).

    静态方法(使用静态类成员的方法除外)在没有上下文的情况下工作，所有数据都必须作为参数传递。我们都知道，在OO代码中，这不是首选的方法。理论上，我们应该寻找与方法最相关的对象，并将该方法移到该对象上。记住，代码共享不必是静态的，它只需要是公共的(或者是可见的)。

    静态方法的移动位置示例：

  • 如果只有一个参数，则返回该参数。
  • 如果有多个参数，请在打开方法之间进行选择：
    • 最常用的参数：具有多个字段或方法的参数，或由条件使用的参数(理想情况下，某些条件将通过重写子类删除)。
    • 一个已经可以很好地访问多个参数的现有对象。
    • 为那个需要建立一个新的类

    • 虽然这种方法的移动对OO纯粹主义者来说似乎是有帮助的，但我们发现从长远来看，这确实有助于我们(而且当我们想要对它进行子类化时，它被证明是非常宝贵的，可以改变一种算法)。Eclipse在不到一分钟的时间内移动一个方法(包括所有的验证)，当我们寻找一些代码或不再编码已经编码的方法时，我们会获得超过一分钟的时间。

    Limitations : some classes can't be extended, usually because they are out of control (JDK, libraries ...). I believe this is the real helper justification, when you need to put a method on a class that you can't change.

    Our good practice then is to name the helper with the name of the class to extend, with Helper suffix. (StringHelper, DateHelper). This close matching between the class where we would like the code to be and the Helper helps us find those method in a few seconds, even without knowledge if someone else in our project wrote that method or not.

    EDCOX1×0后缀是一个很好的约定，因为它在其他语言中使用(至少在爪哇，IrrRails使用它)。

    助手的意图应该通过方法名进行传输，并且只使用类作为占位符。例如，ParseCommaSeparatedIntegersFromString是一个坏名字，原因有两个：

    • 真的太长了
    • 它是多余的，在静态类型语言中，您可以删除FromString后缀，因为它是从签名推导出来的。

    你觉得如何：

    1
    2
    3
    4
    CSVHelper.parse(String)
    CSVHelper.create(int[])
    HTMLHelper.clean(String)
    ...
    相关讨论