有一个没有抽象方法的抽象类有什么意义？

Question

可以有一个实现所有方法的抽象类-里面没有抽象方法。

例如。：

public abstract class someClass { 
    int a; 
    public someClass (int a) { this.a = a; } 
    public void m1 () { /* do something */ } 
    private void m2 () { /* do something else */ }  
}

与拥有与具体类相同的类相比，拥有这样的抽象类（如果有）有什么优势？

我能想到的是，当我将其声明为抽象时，它不会被实例化。 但是，我可以通过将其具体化并将其构造函数设为私有来达到相同的效果。

TIA。

// ==================

编辑：我可以想到的另一种用途：

它可能正在扩展另一个抽象类或实现一个接口，而不实现该类的抽象方法-尽管它正在实现自己的所有方法。 不管它的价值。

Answer 1

• 您可以声明要实现一个接口而不提供实现，然后每个子对象都隐式地获得接口扩展

• 您可以防止创建此类的实例

• 您将来会为所有孩子提供共同的实现

Answer 2

它具有概念上的含义：此类的行为本身没有任何意义。

诚然，很难想象没有明确定义的扩展点（即抽象方法）的情况，但有时这将是问题的合理模型。

你可以有这样的事情：

public abstract class ObjectWithId {
    private final String id;

    public ObjectWithId( String id ) {
       this.id = id;
    }

    public final String getId() {
       return id;
    }
}

然后，您可以扩展它以声明具有ID的不同类型的对象。 在这里，您具有完全指定和实现的行为，但对子类可能没有表现出任何其他行为的限制。

请注意，虽然建模相同事物的一种更整洁的方法是使用合成而不是继承。

public final class ObjectWithId<T> {
    private final String id;
    private final T ob;

    public ObjectWithId( String id, T ob ) {
       this.id = id;
       this.ob = ob;
    }

    public String getId() {
       return id;
    }

    public T getObject() {
       return ob;
    }
}

但是在引入泛型之前（在Java版本1.4之前），这并没有那么优雅，而且显然比抽象类解决方案要好，因为您必须在类型安全性方面进行交易。

Answer 3

如您所指出的，可以通过将其构造函数设为私有来防止实例化该类。 除此之外，没有任何好处。 可能只是为了提供语言完整性而支持此功能。

Answer 4

我们通常将抽象概念与继承一起使用

如果以下任何一种情况适用于您的情况，请考虑使用抽象类：

• 您想在几个紧密相关的类之间共享代码。

---

为了回答您的问题，

Why declare a class with concrete methods Abstract?

一种可能的原因是在不实际创建对象的情况下支持继承

---

假设您有两个类别，一个是“抽象”类别，另一个是“其他”类别

抽象类 ： AbsClass

abstract class AbsClass {
  int a = 5;

  //Constructor
  public AbsClass() {
    System.out.println(a);
  }

  void methodA() {
    System.out.println(a + 10);

  }

}

和具体类 ： ConcreteClass

class ConcreteClass {
  int a = 10;

 //Made the constructor Private to prevent from creating objects of this class
  private ConcreteClass() {
    System.out.println(a);

  }

  void methodA() {
    System.out.println(a + 10);
  }

}

上面的两个类的功能应类似（？），直到尝试对它们进行子类化为止

class AbsImplementer extends AbsClass {
//Works fine

}

class ConcImplementer extends ConcreteClass {
//Compilation Error Implicit super constructor ConcreteClass() is not visible


}

Answer 5

如果您将其视为实用程序类 ，则可能会很有用。

Answer 6

实际的区别在于您无法创建它的实例。 您必须将其子类化并创建该子类的实例。

至于为什么要在实践中这样做呢……我很难想到一个很好的理由。 您可以说该类仅在有人创建实现某些功能的子类时才有意义。 但是，为什么不使该函数在超类中抽象化呢？

我不排除有人提出一个有意义的例子的可能性，但我想不出一个例子。 仅仅因为可以编写一段代码并且该代码可以成功编译并不意味着就可以了。 我的意思是，我可以写“ total_price = item_price * zip_code + customer_height_in_cubits-7.879”，但这并不意味着这样的代码行将有意义。

Answer 7

好吧，假设您不在乎抽象类的方法是实现的还是抽象的，但是通过设计，它必须是抽象的，以便当有人扩展它时，他们必须添加更多方法或重写现有方法或按原样使用。 如果他们不想覆盖这些方法，则该抽象类中已经提供了默认行为。

在这个抽象类中，您强制执行的唯一条件是-一个人无法实例化该类，并且在使用它之前必须拥有其唯一的版本。

因此，总的来说，几乎没有实现任何方法的抽象类比拥有根本没有实现任何方法的接口要好得多。 这是基于您将其用作单个继承的假设。

Answer 8

考虑一下类似于NVI模式的东西（不确定在Java中将其称为什么）：

public abstract class A {
    public final void doSomething() {
        System.out.println("required");
        doOptional();
    }

    protected void doOptional() {
        System.out.println("optional");
    }
}

public class B extends A {
    @Override
    protected void doOptional() {
        System.out.println("overridden");
    }
}

对于您的公共API，您只公开了不能覆盖的public final方法。 它在其中执行一些必需的工作以及一个可选方法。 扩展此类时，只能覆盖doOptional（）。

调用B.doSomething（）始终会在继续之前打印“ required”。

由于doOptional（）不是抽象的，所以没有纯粹的代码原因需要将类A抽象。 但是对于您的特定项目可能是理想的。 例如，基本服务始终扩展到特定的子项目中。

Answer 9

当从抽象基类派生的类必须具有某些彼此不同的行为， 但该行为不能抽象为驻留在对所有类具有相同签名的方法中时，这可能很有用。 如果不同的行为需要传递不同的原始类型的方法，则可能无法共享签名。 因为它们使用原始类型，所以不能使用泛型来表达相似性。

没有任何抽象方法的抽象基类的行为有点像标记接口 ，因为它声明实现类必须提供某种行为，而不能将该行为封装在新方法中，而该方法的签名对于所有实现都是相同的。 当实现类具有某些共同的行为时，您将使用抽象基类而不是标记接口，尤其是如果基类可以为派生类实现它时。

例如：

abstract class Sender {
   protected final void beginMessage() {
      ...
   }

   protected final void endMessage() {
      ...
   }

   protected final void appendToMessage(int x) {
      ...
   }
 }

 final class LongSender extends Sender {
    public void send(int a, int b, int c) {
       beginMessage();
       appendToMessage(a);
       appendToMessage(b);
       appendToMessage(c);
       endMessage();
    }
 }

 final class ShortSender extends Sender {
    public void send(int a) {
       beginMessage();
       appendToMessage(a);
       endMessage();
    }
 }