何时选用密封接口包装器而非普通接口？代码场景疑问

背景代码对比 #

原有实现（普通接口继承） #

interface Offer {
    val sharedProperty: Property
}

class Product(...): Offer {
    override...
}

class Category(...): Offer {
    override...
}

fun Offer.doSomething(...) {
    when(this) {
        is Product -> ...
        is Category -> ...
        else -> <handle not supported implementation>
    }
}

重构后的包装模式（密封接口包装器） #

class Product(...)

class Category(...)

sealed interface Offer {

    val sharedProperty: Property

    class ProductOffer(
        val product: Product // 注：原代码疑似笔误，应为Product而非Offer
        override...
    ): Offer

    class CategoryOffer(
        val category: Category
        override...
    ): Offer
}

fun Offer.doSomething(...) {
    when(this) {
        is ProductOffer -> ...
        is CategoryOffer -> ...
    }
}

核心问题 #

我已明确「包含对象」与「成为对象」模式的语义差异，也知晓外部类无法实现该密封接口，但想了解该包装模式还有哪些潜在陷阱？同时想明确何时应选用密封接口包装器而非普通接口？

潜在陷阱 #

• 层级复杂度增加：每个业务类对应一个包装类，额外增加了代码量和认知成本。访问原对象属性时需要多一层间接调用（如ProductOffer.product.xxx），调试链路也更长。
• 状态同步风险：若原业务类（Product/Category）内部状态变化，包装类的sharedProperty若依赖原对象状态，需手动同步，容易出现数据不一致问题。
• 代码重复冗余：多个包装类实现Offer接口时，相同逻辑无法直接复用，需重复编写或额外抽取工具类，进一步提升复杂度。
• 扩展性受限：新增Offer类型必须修改密封接口定义，违反开闭原则；而普通接口允许外部新增实现类，无需改动原有代码。
• 序列化/反序列化复杂度提升：包装类嵌套结构会增加序列化的难度，需确保嵌套对象正确序列化，还要处理不同包装类的类型识别逻辑。

适用场景 #

• 严格限制实现范围：当明确Offer只有有限几种实现，且不允许外部随意新增时，密封接口可避免when表达式的else分支，保证编译时完整性检查。
• 职责分离需求：希望原业务类（Product/Category）只负责自身核心逻辑，把Offer相关逻辑集中在包装类中，实现职责清晰的单一原则。
• 编译时安全保障：需要强制覆盖所有可能的Offer类型，避免遗漏分支导致的运行时错误，密封接口能让编译器自动检查所有实现类。
• 原类不可修改：若Product/Category是第三方类或已被广泛使用，无法直接修改让其实现Offer接口，包装模式可在不改动原类的前提下扩展其行为。

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