Java服务构造参数与成员变量：选抽象接口还是具体实现类？

我是Java新手，想请教一个问题：我定义了如下仓储接口：

public interface Repository<T, K> {
    T get(K id);
    // 其他方法
}

还有两个实现类：

public class RepositoryOne implements Repository<EntityOne, Long> {
    // 方法实现
}

public class RepositoryTwo implements Repository<EntityTwo, Long> {
    // 方法实现
}

现在要写一个使用其中一个仓储实现的服务，下面四种写法语法都合法，哪种更合适？它们之间有什么区别？

1. 构造参数与成员变量均为具体类 #

public class SomeService{
    private final RepositoryOne repositoryOne;

    public SomeService(RepositoryOne repositoryOne) {
        this.repositoryOne = repositoryOne;
    }

    // 业务方法
}

分析：

• 优势：代码直接简单，无需类型转换，调用RepositoryOne特有的方法时很方便。
• 劣势：耦合度极高，SomeService完全绑定了RepositoryOne。后续要替换成其他实现了Repository<EntityOne, Long>的类时，必须修改SomeService的代码，违反了依赖倒置原则（面向抽象而非具体实现编程）。单元测试时也只能用真实的RepositoryOne实例，无法轻松Mock。

2. 成员变量为接口，构造参数为具体类 #

public class SomeService{
    private final Repository<EntityOne, Long> repositoryOne;

    public SomeService(RepositoryOne repositoryOne) {
        this.repositoryOne = repositoryOne;
    }

    // 业务方法
}

分析：
这种写法意义有限，相当于只做了一半的抽象。

• 虽然成员变量依赖抽象接口，但构造参数限制了只能传入RepositoryOne实例，依然没解决耦合问题——替换实现类时还是要修改构造方法参数类型，单元测试也只能用RepositoryOne相关实例，没发挥出面向接口编程的优势。

3. 构造参数与成员变量均为接口 #

public class SomeService{
    private final Repository<EntityOne, Long> repositoryOne;

    public SomeService(Repository<EntityOne, Long> repositoryOne) {
        this.repositoryOne = repositoryOne;
    }

    // 业务方法
}

分析：
这是最符合依赖倒置原则和面向接口编程思想的写法。

• 优势：耦合度极低，SomeService只依赖抽象的Repository接口，不关心具体实现。后续可以轻松替换成任何实现了Repository<EntityOne, Long>的类（比如RepositoryOne的子类、新的RepositoryThree），不需要修改SomeService的代码；单元测试时可以方便地Mock一个Repository<EntityOne, Long>实例，隔离依赖，提高测试效率。
• 劣势：如果需要调用RepositoryOne特有的、接口未定义的方法，这种写法做不到。这时优先考虑把方法提升到接口中（如果业务逻辑允许），如果确实无法提升，才考虑其他方案。

4. 构造参数为接口，成员变量为具体类并强制转换 #

public class SomeService{
    private final RepositoryOne repositoryOne;

    public SomeService(Repository<EntityOne, Long> repositoryOne) {
        this.repositoryOne = (RepositoryOne) repositoryOne;
    }

    // 业务方法
}

分析：
这种写法存在严重的运行时风险，不推荐使用。

• 虽然构造参数是接口，但内部强制转换成RepositoryOne，如果传入的是其他实现了Repository<EntityOne, Long>的类，运行时会抛出ClassCastException，这个错误编译期无法发现。
• 本质上还是依赖具体实现，既没获得面向接口编程的灵活性，又引入了不必要的运行时风险，完全得不偿失。

总结 #

如果服务只需要使用Repository接口定义的方法，第3种写法是最优选择，它遵循了面向对象设计的核心原则，代码更灵活、可维护性更高。

如果服务必须调用RepositoryOne特有的方法，优先考虑把这些方法抽象到Repository接口中。如果确实无法抽象，只能选择第1种写法，但要接受耦合度高的代价，绝对要避免第4种写法。

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