非完全抽象类相较于完全抽象类（absolutely abstract class）的技术优势有哪些？

Awesome question! Let's dive into the practical technical advantages of using a non-absolute abstract class (which mixes abstract and concrete methods) over an absolutely abstract class (where every method is abstract):

• Code Reuse & Default Implementations
  The biggest win is cutting down redundant code across subclasses. You can define common behavior in concrete methods that all subclasses inherit directly, instead of forcing each subclass to reimplement the same logic. For example, a Shape abstract class might require subclasses to implement calculateArea() (abstract), but provide a default printDetails() method that leverages the area calculation:

  abstract class Shape {
      public abstract double calculateArea();
  
      // Concrete default method
      public void printDetails() {
          System.out.printf("Area of this shape: %.2f%n", calculateArea());
      }
  }
  
  class Square extends Shape {
      private double side;
  
      public Square(double side) { this.side = side; }
  
      @Override
      public double calculateArea() { return side * side; }
      // No need to write printDetails()—it's inherited automatically
  }
  

  This follows the DRY (Don't Repeat Yourself) principle and keeps your codebase clean and maintainable.

• Smoother API Evolution
  When you need to add new functionality to your abstract class later, non-absolute abstract classes let you add concrete methods with default implementations. This means existing subclasses don't break—they can use the new method as-is or override it if needed. With an absolutely abstract class, adding any new method forces all subclasses to implement it immediately, which is a breaking change. For example, if you later add a getPerimeter() method to Shape with a default (maybe throwing an exception for shapes that don't have one), existing subclasses like Square can choose to implement it later without breaking current code.

• Encapsulation of Shared Business Logic
  You can wrap complex, shared logic in the abstract class's concrete methods, ensuring consistency across all subclasses. For instance, a PaymentProcessor abstract class might have an abstract processPayment() method, but a concrete validatePaymentDetails() method that checks for common issues (like empty card numbers, invalid expiry dates) that all payment types need to handle. Subclasses don't have to reinvent this validation logic—they just call the parent method, making sure all payments follow the same rules.

• Helper Methods for Subclasses
  Non-absolute abstract classes can provide utility or helper methods that subclasses can leverage to simplify their own implementations. For example, a BaseRepository abstract class for database operations might have an abstract findById() method, but a concrete getDatabaseConnection() method that handles connection pooling and setup. Subclasses don't need to worry about the nitty-gritty of connecting to the database—they just reuse the helper method.

• Balanced Flexibility & Contract Enforcement
  These classes strike a perfect balance: they enforce that subclasses implement critical, unique behavior (via abstract methods) while providing default behavior for less variable tasks. Subclasses can choose to override concrete methods if they need custom behavior, but aren't forced to rewrite everything. This gives you control over the core contract of the class, while still letting subclasses adapt where necessary.

内容的提问来源于stack exchange，提问作者Md. Asaduzzaman