您对如何组织和命名实用程序类有任何意见吗？
每当我遇到一些代码复制时,可能只是几个代码行,我将它们移动到实用程序类.
过了一会儿,我往往会得到很多的小静态类,通常只有一个方法,我usualy放在一个utility是它和类臃肿的命名空间.
例子:
ParseCommaSeparatedIntegersFromString( string ) CreateCommaSeparatedStringFromIntegers( int[] ) CleanHtmlTags( string ) GetListOfIdsFromCollectionOfX( CollectionX ) CompressByteData( byte[] )
通常,命名约定会告诉您将类命名为名词.我经常最终得到很多类HtmlHelper,CompressHelper但它们的信息量不大.我也尝试过非常具体的HtmlTagCleaner,通常每个实用程序方法最终会有一个类.
您对如何命名和分组这些辅助方法有任何想法吗？
我认为有一个复杂的连续体,因此相应的组织.示例如下,根据项目和实用程序的复杂程度进行选择,并适应其他约束:
一个类(称为Helper),有几个方法
一个包(称为helper),有几个类(称为XXXHelper),每个类都有几个方法.或者,如果类适合,则可以将这些类分成几个非辅助包.
一个项目(称为帮助程序),带有一些程序包(称为XXX),每个程序包都包含...或者,如果适合,程序包可以分成几个非辅助程序包.
几个辅助项目(按层,按使用中的库或其他方式分开)......
在每个分组级别(包,类):
意义的共同部分是分组名称的名称
内部代码不再需要那个含义(所以他们的名字更短,更集中,不需要缩写,它使用全名).
对于项目,我通常在超级包名称中重复常见含义.虽然理论上不是我的首选,但我没有在我的IDE(Eclipse)中看到导入类的项目,所以我需要重复这些信息.该项目实际上仅用作:
运输单位:一些可交付物或产品将有罐子,那些不需要它的罐子,
表达依赖关系:例如,业务项目不依赖于Web层帮助程序; 表示在项目依赖性方面,我们对表观复杂性进行了改进,对我们有益; 或者发现这种依赖,我们知道出了什么问题,并开始调查......; 此外,通过减少依赖性,我们可以加快编译和构建....
对代码进行分类,以便更快地找到它:只有当代码很大时,我才会谈论项目中的数千个类
请注意,以上所有内容也适用于动态方法,而不仅仅是静态方法.这实际上是我们所有代码的良好实践.
既然我试图回答你的问题(虽然是广泛的),让我再加上一个想法
(我知道你没有要求).
静态方法(使用静态类成员除外)在没有上下文的情况下工作,所有数据都必须作为参数传递.我们都知道,在OO代码中,这不是首选方式.理论上,我们应该寻找与该方法最相关的对象,并在该对象上移动该方法.请记住,代码共享不必是静态的,只需要公开(或以其他方式可见).
移动静态方法的示例:
如果只有一个参数,则为该参数.
如果有多个参数,请选择移动方法:
最常用的参数:使用了多个字段或方法的参数,或条件语句使用的参数(理想情况下,子类覆盖会删除某些条件)...
一个已经很好地访问了几个参数的现有对象.
为这种需求构建一个新类
虽然这种方法可能看起来像OO-purist,但我们发现从长远来看这实际上对我们有所帮助(当我们想要子类化它来改变算法时它证明是无价的).Eclipse在不到一分钟的时间内(通过所有验证)移动一个方法,当我们查找一些代码时,或者当我们不再编码已经编码的方法时,我们获得了超过一分钟的时间.
限制:某些类无法扩展,通常是因为它们失控(JDK,库......).我相信这是真正的帮助理由,当你需要将一个方法放在一个你无法改变的类上时.
我们的良好做法是使用Helper后缀为要使用要扩展的类的名称命名助手.(StringHelper,DateHelper).我们希望代码所在的类和Helper之间的这种紧密匹配有助于我们在几秒钟内找到这些方法,即使我们的项目中有其他人写过该方法也不知道.
Helper后缀是一个很好的约定,因为它用于其他语言(至少在Java中,IIRC rails使用它).
应该通过方法名称传输助手的意图,并仅将该类用作占位符.例如ParseCommaSeparatedIntegersFromString,由于以下几个原因,这是一个糟糕的名称:
太久了,真的
它是多余的,在静态类型语言中,您可以删除FromString后缀,因为它是从签名推断出来的
你有什么想法:
CSVHelper.parse(String) CSVHelper.create(int[]) HTMLHelper.clean(String) ...
京公网安备 11010802040832号 | 京ICP备19059560号-6 