抽象类可无抽象方法，只要用abstract修饰即禁止实例化，核心是表达“不可单独使用”的基类契约，同时支持复用字段、构造逻辑和默认行为。
可以，Java 抽象类完全允许不包含任何抽象方法。
核心目的不是定义“未实现的方法”，而是禁止实例化
只要类声明了 abstract 修饰符，它就不可被 new 出来，无论里面有没有 abstract 方法。这种设计的关键在于：你希望提供一套可复用的逻辑或结构，但又不希望开发者直接创建这个类的对象。
- 比如 HttpServlet：所有方法都有默认实现（doGet、doPost 等都是具体方法），但它仍是 abstract 类——只为防止有人误写
new HttpServlet() - 再如 MouseAdapter：每个方法体都是空的
{}，但它标记为 abstract，让子类能只重写关心的事件，不用强行实现全部接口方法 - 还有 Spring 的 AbstractController 或 JDK 的 AbstractList：封装了通用流程和字段，子类只需补一两个关键方法就能工作
什么情况下适合用“无抽象方法”的抽象类
当你要表达“这是一个基类，但不能单独用”，同时又想给子类提供构造逻辑、共享字段、protected 工具方法或默认行为时，就适合。
- 需要子类共用某些初始化步骤？→ 抽象类可定义带参构造器，子类通过
super(...)调用 - 有状态要继承（比如配置对象、连接池引用）？→ 抽象类支持实例字段；接口做不到
- 想提供包内可见或 protected 的辅助方法？→ 接口无法定义非 public 成员
- 已有类已继承了其他父类，又想复用某套行为？→ 只能靠抽象类做中间层（因为 Java 不支持多继承）
怎么判断该不该这么设计
如果一个类标了 abstract 却既没有抽象方法，也不提供任何可复用逻辑、字段或构造支持，那它大概率设计错了。
- 若只是想“禁止实例化”且无复用内容 → 改用普通类 + 私有构造器更清晰
- 若重点是定义能力契约（比如“能保存、能查询”）→ 应该用 interface，尤其当多个不相关类都需要这些能力时
- 若强调“是一种 XXX”，且需要共享实现细节 → abstract class 更自然，哪怕暂时没抽象方法
实际写法示例
一个纯模板型抽象类：
abstract class DataProcessor {
protected final Logger logger = LoggerFactory.getLogger(getClass());
// 默认预处理逻辑
protected void beforeProcess() {
logger.info("Starting process...");
}
// 默认后处理逻辑
protected void afterProcess() {
logger.info("Process completed.");
}
// 模板方法：定义流程骨架
public final void execute() {
beforeProcess();
doActualWork(); // 留给子类实现
afterProcess();
}
// 这才是唯一需要子类实现的抽象方法
protected abstract void doActualWork();
}
注意：这里只有一处 abstract 方法，但即使把它也去掉（比如先留空实现），只要类仍需作为基类被继承且不应被实例化，声明为 abstract 依然合理。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
