不推荐空实现——虽语法合法，但易致调用方误解、维护成本高；应优先用abstract声明、default方法或抛UnsupportedOperationException。
可以，但不推荐——空实现（{}）在语法上合法，但语义上容易引发误解和维护风险。
空实现是语法合法的
抽象类实现接口时，如果选择提供方法体而非声明为 abstract，哪怕方法体为空（即只写 {}），编译器也允许。例如：
interface Service {
void start();
void stop();
}
abstract class BaseServiceImpl implements Service {
@Override
public void start() { } // ✅ 合法：空方法体
@Override
public void stop() { } // ✅ 合法
}
这种写法不会报错，因为抽象类本就不强制实现接口方法；提供空体只是“实现”了语法要求，并未违反规则。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
但空实现与抽象声明有本质区别
-
空实现 = 已履行契约：该方法已有具体实现（哪怕什么也不做），子类继承后可直接调用，无需重写；若子类想改变行为，需显式
@Override覆盖。 -
声明 abstract = 主动留白：如
public abstract void start();，明确表示“此处不提供逻辑，必须由非抽象子类落实”，语义清晰、职责分明。
为什么通常不建议空实现？
空实现容易造成以下问题：
立即学习“Java免费学习笔记（深入）”；
- 调用方误以为该方法已具备基础行为（比如日志、校验、资源初始化），实际却什么都没做，导致运行时异常或逻辑遗漏；
- 后续维护者难以判断这是“暂时留空”还是“有意忽略”，增加理解成本；
- 若多个抽象类都对同一接口方法做空实现，会掩盖设计意图，削弱接口契约的约束力。
更合理的替代方案
根据设计意图，优先考虑以下方式：
- 若该方法确实不该由当前抽象层处理 → 声明为
public abstract，让子类强制实现； - 若需提供统一的默认空行为（比如“不执行任何操作”本身就是一种策略）→ 使用接口的
default方法，更自然、更符合接口演进原则； - 若需占位但预留扩展点 → 可抛出
UnsupportedOperationException并加注释，比静默空实现更具警示性。
