标记接口与空抽象类的选择困境：两类无结构关联类的订阅需求

嘿，这个纠结我太懂了！标记接口空得像个摆设，完全违背了接口“定义行为契约”的初衷；硬套空抽象类又平白给两个毫无结构关联的类加了继承层级，怎么想都别扭。咱们换个思路，从你的核心需求出发——让BrokerResponse和Notification支持订阅（也就是register方法），其实有更贴合面向对象设计的方案：

1. 用带行为的接口替代标记接口 #

既然核心需求是“支持订阅”，那直接把register方法放进接口里啊！这样接口不再是空的标记，而是明确了“可订阅”的行为契约，完美解决你反感标记接口的问题。

示例代码：

// 定义真正的行为接口，而非空标记
public interface Subscribable {
    void register(Receivable receivable, BrokerObserver observer);
}

// 让两个类分别实现接口，各自处理订阅逻辑
public class BrokerResponse implements Subscribable {
    @Override
    public void register(Receivable receivable, BrokerObserver observer) {
        // BrokerResponse专属的订阅实现逻辑
    }
}

public class Notification implements Subscribable {
    @Override
    public void register(Receivable receivable, BrokerObserver observer) {
        // Notification专属的订阅实现逻辑
    }
}

这种方式完全符合接口的设计初衷，既给两个类建立了“可订阅”的行为关联，又没有强制它们共享结构，灵活度拉满。

2. 有复用逻辑？用组合代替继承 #

如果BrokerResponse和Notification的register逻辑有部分重复，别想着用抽象类继承来复用——组合才是更灵活的选择。把通用逻辑抽成一个独立的处理类，然后在两个业务类里组合它：

示例代码：

// 抽离通用订阅逻辑
public class SubscriptionManager {
    public void processRegistration(Receivable receivable, BrokerObserver observer) {
        // 通用的订阅处理逻辑，比如校验参数、记录日志等
    }
}

// BrokerResponse组合SubscriptionManager实现接口
public class BrokerResponse implements Subscribable {
    private final SubscriptionManager subscriptionManager = new SubscriptionManager();

    @Override
    public void register(Receivable receivable, BrokerObserver observer) {
        // 先调用通用逻辑
        subscriptionManager.processRegistration(receivable, observer);
        // 再添加BrokerResponse的专属逻辑
    }
}

组合避免了单一继承的限制，也不会给业务类引入不必要的父类层级，后续扩展更方便。

3. 真的只需要标记？用注解替代标记接口 #

如果你的场景里，register方法不是必须在接口里定义（比如只是给框架做反射标记用），那自定义注解比空标记接口更合适——语义更清晰，也不会占用接口名额：

示例代码：

// 定义运行时可见的自定义注解
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface Subscribable {}

// 给两个类打上注解标记
@Subscribable
public class BrokerResponse {
    // ... 类逻辑
}

@Subscribable
public class Notification {
    // ... 类逻辑
}

注解的标记语义比空接口明确得多，而且现代框架对注解的支持也非常成熟。

总结 #

你纠结的两个选项都不是最优解：

• 标记接口违背接口的行为契约本质
• 空抽象类强行绑定无结构关联的类，破坏继承体系

最贴合你需求的方案是带行为的接口+按需组合，既满足了“支持订阅”的核心需求，又完全符合面向对象的设计原则。

内容的提问来源于stack exchange，提问作者tgr