如何结合‘面向接口编程’范式与Builder模式保障对象有效性？

这确实是个很典型的设计矛盾——你既想用Builder保证对象的不可变性与合法性，又想遵循面向接口编程的原则，结果发现接口的开放性打破了Builder构建的安全边界。你完全没忽略要点，这本来就是两种设计思路的天然冲突点，不过我们有几种办法来整合它们：

方案一：隐藏具体实现，通过Builder对外暴露接口实例 #

这是最直接也最可靠的解决方案，核心思路是把合法对象的创建权完全收归Builder，同时对外只暴露接口：

1. 将PersonImpl设为包私有，让外部代码无法直接访问或继承它；
2. 提供一个对外的PersonBuilder，直接返回Person接口类型；
3. 所有验证逻辑依然留在Builder中，确保只有合法的实例能被创建。

修改后的代码示例：

// 包私有实现类，外部无法访问或继承
final class PersonImpl implements Person {
    private final LocalDate birthday;

    // 包私有构造方法，仅能被Builder调用
    PersonImpl(LocalDate birthday) {
        this.birthday = birthday;
    }

    @Override
    public LocalDate getBirthday() {
        return birthday;
    }
}

// 对外暴露的Builder，返回Person接口
public class PersonBuilder {
    private LocalDate birthday;

    public PersonBuilder setBirthday(LocalDate birthday) {
        this.birthday = birthday;
        return this; // 链式调用更符合Builder风格
    }

    public Person build() {
        if (birthday == null || birthday.isAfter(LocalDate.now().minusYears(21).minusDays(1))) {
            throw new IllegalStateException("Person must be 21 years or above");
        }
        return new PersonImpl(birthday);
    }
}

// API依然保持面向接口设计
public interface PersonService {
    void doSomeAdultStuff(Person person);
}

这样一来：

• 客户端只能通过PersonBuilder获取合法的Person实例，无法自己实现Person接口（因为没有可访问的实现类作为参考，且自定义实现也无法通过你的API的隐含契约）；
• 你的PersonService依然面向Person接口编程，完全符合“面向接口而非实现”的原则；
• 所有Person实例的不可变性与合法性都由Builder严格保证。

方案二：在API入口处添加契约验证 #

如果必须允许外部实现Person接口（比如需要支持第三方扩展），那可以在API的业务逻辑入口处，强制验证传入对象是否符合契约：

public class PersonServiceImpl implements PersonService {
    @Override
    public void doSomeAdultStuff(Person person) {
        // 每次接收Person对象时都验证合法性
        validatePerson(person);
        // 后续业务逻辑
    }

    private void validatePerson(Person person) {
        if (person.getBirthday() == null || person.getBirthday().isAfter(LocalDate.now().minusYears(21).minusDays(1))) {
            throw new IllegalArgumentException("Invalid Person: must be 21 years or above");
        }
    }
}

这个方案的优缺点很明显：

• 优点：保留了接口的开放性，同时保证了业务逻辑只处理合法对象；
• 缺点：验证逻辑会重复执行（如果多个API方法都需要验证），且无法保证对象的不可变性（外部实现可能提供可变的getBirthday方法）。

方案三：用抽象类替代接口（谨慎选择） #

如果你的场景不需要多继承，可以用抽象类代替接口，把实现类嵌套在抽象类中并设为私有，同时提供静态Builder方法：

public abstract class Person {
    public abstract LocalDate getBirthday();

    // 私有实现类
    private static final class PersonImpl extends Person {
        private final LocalDate birthday;

        private PersonImpl(LocalDate birthday) {
            this.birthday = birthday;
        }

        @Override
        public LocalDate getBirthday() {
            return birthday;
        }
    }

    // 对外暴露的Builder方法
    public static Builder builder() {
        return new Builder();
    }

    public static class Builder {
        private LocalDate birthday;

        public Builder setBirthday(LocalDate birthday) {
            this.birthday = birthday;
            return this;
        }

        public Person build() {
            if (birthday.isAfter(LocalDate.now().minusYears(21).minusDays(1))) {
                throw new IllegalStateException("Person must be 21 years or above");
            }
            return new PersonImpl(birthday);
        }
    }
}

这种方式也能保证对象的合法性与不可变性，同时对外暴露的是抽象类（类似接口的作用），但缺点是牺牲了Java的多继承灵活性，所以只适合不需要实现其他接口的场景。

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