助手/实用程序类应该是抽象的吗?

我经常发现自己将常见的行为从类中提取到辅助类/实用类中,该类只包含一组静态方法。 我经常想知道是否应该将这些类声明为抽象的,因为我不能真正想到一个有效的理由来实例化这些类。

优点和缺点是什么将宣布这样一个类抽象。

public [abstract] class Utilities{ public static String getSomeData(){ return "someData"; } public static void doSomethingToObject(Object arg0){ } } 

10 Solutions collect form web for “助手/实用程序类应该是抽象的吗?”

你可以声明一个私有的构造函数,它什么也不做。

声明类“抽象”的问题是抽象关键字通常意味着该类将被分类和扩展。 这绝对不是你想要的。

不要打扰他们抽象,但包括一个私人的无参数构造函数,以防止他们被实例化。

有兴趣的人可以比较一下:在C#中,你会声明这个类是静态的,使它在编译后的forms中是抽象的封闭的(Java的final),并且没有任何实例构造器。 这也使得它声明一个参数,variables,数组等types的编译时错误。 便利。

我不宣布实用程序类抽象,我宣布他们最后,并使构造函数私人。 这样他们不能被分类,他们不能被实例化。

 public final class Utility { private Utility(){} public static void doSomethingUseful() { ... } } 

通过将它们声明为抽象的,您实际上向其他编码人员表明您打算从这些类派生出来。 真的,你说的没错,但是这里的语义实际上更多的是关于其他人看你的代码的解释。

正如其他人所说,做一个私人参数较less的构造函数。 除了课程本身,没有人可以创build它的一个实例。

正如其他人已经展示了如何使用其他语言完成的,下面是在下一个C ++版本中如何做到这一点,如何使一个类不可实例化:

 struct Utility { static void doSomething() { /* ... */ } Utility() = delete; }; 

我会添加更多的步骤超出私人的构造函数:

 public class Foo { // non-instantiable class private Foo() { throw new AssertionError(); } } 

抛出AssertionError阻止同一个类中的方法实例化这个类(他们可以尝试)。 这通常不是一个问题,但在团队环境中,你永远不会知道某人会做什么。

关于“抽象”关键字,我注意到在许多情况下,实用程序类被分类:

 public class CoreUtils { ... } public class WebUtils extends CoreUtils { ... } public class Foo { ... WebUtils.someMethodInCoreUtils() ... } 

我相信这样做是为了让人们不必记住包含哪个工具类。 这有什么缺点吗? 这是反模式吗?

问候,LES

不,但是如果你的语言支持它的话,有一个强有力的论据是,在大多数情况下,它们应该被声明为“静态的”。Static告诉编译器它们不能被实例化,并且它们中的所有方法必须是静态的。

摘要是为那些有基于实例的实现细节的类,这些细节将被派生类的实例使用。

有人提到,在C#3.0中,你可以通过扩展方法来完成。 我不是C#的人,在1.5 / 2.0的时候做了一些,但从那以后就没有用过。 基于一个非常粗略的理解,我认为类似的东西可以在静态导入java中完成。 我意识到它并不完全一样,但如果目标是让这些效用方法对于调用类来说显得更加“本土化”(因为没有更好的术语),我认为它会起作用。 假设我在原来的问题中声明了实用程序类。

 import static Utilities.getSomeData; public class Consumer { public void doSomething(){ String data = getSomeData(); } } 

我可以提供一些build设性的意见吗?

如果你正在做很多这个,你会碰到两个问题。

首先,采用参数的静态方法通常应该是该参数对象的一部分。 我意识到这并不能帮助像String这样的对象,但是如果它需要你定义的对象,你几乎可以肯定的通过把你的帮助器作为该对象的方法来改进对象。

如果它采用所有的本地值,你可能可以定义一个对象,这是一个方法。 查看是否可以find这些原生值的任何分组,并将它们分组为对象。 如果你只是尝试一下,你会发现很多其他用途的小对象,而在你知道它之前,这将是非常有用的。

另一件事,如果你有一个半相关的静态方法和静态variables的工具类,你几乎总是希望它是一个单身。 我通过试验和错误发现了这一点,但是当你发现你需要超过1个(最终你会),把单例变成一个多重单元(?)更容易,然后试图将一个静态类变成一个多重单元好的,所以我现在正在说话)。

祝你好运。 这个东西大部分是对我来说是试错的 – 就像5年前一样,我从来没有发现过一个我后悔没有静态类/方法的例子。

助手/工具方法就好了。 不要担心将它们添加到应用程序或Framework中的库中。 我见过的大多数框架使用它们的种类很多。

这就是说,如果你想对他们真的很狡猾,你应该看看C#3.0中的扩展方法 。 使用扩展方法将使你的实用程序更多地成为你的框架的“整体”部分,看起来就像你正在考虑使它们抽象一样。 更不用说扩展方法,写了很多乐趣!

  • 内部抽象类:如何隐藏程序集外的用法?
  • 从抽象类中获取具体的类名称
  • 抽象类和接口有什么区别?
  • 如何使用JUnittestingJava中的抽象类?
  • 为什么java.lang.Object不是抽象的?
  • C#中抽象类的构造方法
  • 模板还是抽象基类?
  • Visual Studio:如何显示从基类inheritance的所有类?
  • 自定义属性对抽象属性的inheritance
  • 何时使用接口而不是抽象类,反之亦然?
  • 在Objective-C中创build一个抽象类