实用程序类和方法的命名约定和结构 [英] Naming convention and structure for utility classes and methods

问题描述

您对如何组织和命名实用程序类有任何意见吗?

Do you have any input on how to organize and name utility classes?

每当我遇到一些代码重复时，可能只是几行代码，我便将它们移至实用程序类.

Whenever I run in to some code-duplication, could be just a couple of code lines, I move them to a utility class.

过一会儿，我倾向于得到很多小的静态类，通常只有一个方法，我通常将其放在utility命名空间中，该命名空间会充斥类.

After a while, I tend to get a lot of small static classes, usually with only one method, which I usualy put in a utility namespace that gets bloated with classes.

示例:

ParseCommaSeparatedIntegersFromString( string )
CreateCommaSeparatedStringFromIntegers( int[] )
CleanHtmlTags( string )
GetListOfIdsFromCollectionOfX( CollectionX )
CompressByteData( byte[] )

通常，命名约定会告诉您将类命名为名词.我经常会遇到很多类似HtmlHelper，CompressHelper的类，但它们的信息量不是很大.我还尝试过像HtmlTagCleaner那样非常具体，通常每个实用程序方法只有一个类.

Usually, naming conventions tell you to name your class as a Noun. I often end up with a lot of classes like HtmlHelper, CompressHelper but they aren't very informative. I've also tried being really specific like HtmlTagCleaner, which usualy ends up with one class per utility method.

您对如何命名和组合这些辅助方法有任何想法吗?

Have you any ideas on how to name and group these helper methods?

推荐答案

我相信存在着一个连续的复杂性，因此存在相应的组织.随后的示例，根据您的项目和实用程序的复杂性进行选择，并适应其他约束条件:

I believe there is a continuum of complexity, therefore corresponding organizations. Examples follow, choose depending of the complexity of your project and your utilities, and adapt to other constraints :

1. 一个类(称为Helper)，其中包含几种方法
2. 一个包(称为帮助程序)，带有几个类(称为XXXHelper)，每个类带有几个方法. 另外，如果合适，可以将这些类分为几个非帮助程序包.
3. 一个项目(称为帮助程序)，带有几个程序包(称为XXX)，每个程序包都包含... 另外，如果合适，可以将这些程序包拆分为几个非帮助程序包.
4. 多个帮助程序项目(按层，使用中的库或其他方式拆分)...

1. One class (called Helper), with a few methods
2. One package (called helper), with a few classes (called XXXHelper), each class with a few methods. Alternatively, the classes may be split in several non-helper packages if they fit.
3. One project (called helper), with a few packages (called XXX), each package with ... Alternatively, the packages can be split in several non-helper packages if they fit.
4. Several helper projects (split by tier, by library in use or otherwise)...

在每个分组级别(包，类):

At each grouping level (package, class) :

• 含义的常见部分是分组名称的名称
• 内部代码不再需要该含义(因此，其名称更短，更集中并且不需要缩写，它使用全名).

• the common part of the meaning is the name of the grouping name
• inner codes don't need that meaning anymore (so their name is shorter, more focused, and doesn't need abbreviations, it uses full names).

对于项目，我通常在超级包名称中重复通常的含义.尽管从理论上讲不是我的首选，但是在我的IDE(Eclipse)中看不到从哪个项目中导入类，因此我需要重复这些信息.该项目实际上仅用作:

For projects, I usually repeat the common meaning in a superpackage name. Although not my prefered choice in theory, I don't see in my IDE (Eclipse) from which project a class is imported, so I need the information repeated. The project is actually only used as :

• 运输单位:某些可交付成果或产品将装有罐子，不需要的罐子或罐子将没有罐子，
• 表示依赖关系:例如，一个业务项目不依赖于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代码中，这不是首选的方式.从理论上讲，我们应该寻找与该方法最相关的对象，并将该方法移至该对象上.请记住，代码共享不一定必须是静态的，而只能是公开的(或其他可见的).

Static methods (except those using static class members) work without context, all data have to be passed as parameters. We all know that, in OO code, this is not the preferred way. In theory, we should look for the object most relevant to the method, and move that method on that object. Remember that code sharing doesn't have to be static, it only has to be public (or otherwise visible).

将静态方法移至何处的示例:

Examples of where to move a static method :

1. 如果只有一个参数，则为该参数.
2. 如果有多个参数，请在将方法移至上进行选择:
   • 最常用的参数:使用多个字段或方法的一个参数，或由条件语句使用的参数(理想情况下，某些条件语句将被子类重写覆盖)...
   • 一个已经可以很好地访问多个参数的现有对象.
   • 为此创建一个新类

1. If there is only one parameter, to that parameter.
2. If there are several parameters, choose between moving the method on :
   • the parameter that is used most : the one with several fields or methods used, or used by conditionals (ideally, some conditionnals would be removed by subclasses overriding) ...
   • one existing object that has already good access to several of the parameters.
   • build a new class for that need

尽管这种方法对于OO纯粹主义者而言似乎是可行的，但从长远来看，我们发现这实际上对我们有帮助(并且当我们希望对其进行子类化，改变算法时，它被证明是无价的). Eclipse在不到一分钟的时间内(通过所有验证)移动了一个方法，当我们查找某些代码或不再对已经编码的方法进行编码时，我们将获得超过一分钟的收益.

Although this method moving may seem for OO-purist, we find this actually helps us in the long run (and it proves invaluable when we want to subclass it, to alter an algorithm). Eclipse moves a method in less than a minute (with all verifications), and we gain so much more than a minute when we look for some code, or when we don't code again a method that was coded already.

限制:某些类无法扩展，通常是因为它们不受控制(JDK，库...).我相信，这是真正的助手理由，当您需要在无法更改的类上放置方法时.

然后，我们的优良作法是使用扩展名后缀为要扩展的类的名称来命名帮助程序. (StringHelper，DateHelper).我们希望代码所在的类和Helper之间的这种紧密匹配可以帮助我们在几秒钟内找到那些方法，即使不知道我们项目中是否有人编写了该方法.

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.

这篇关于实用程序类和方法的命名约定和结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！