接口间的循环依赖会引发哪些设计层面的问题？

接口之间的循环依赖不像类的循环依赖那样可能直接触发编译错误，但会给设计、维护和复用带来一系列隐性问题：

• 职责边界模糊，违背单一职责：接口的核心是聚焦自身业务能力，像示例中的Employee和Department，各自都绑定了对方的关联获取逻辑，导致每个接口都要兼顾与对方的耦合关系，没法专注处理自身核心逻辑。
• 维护成本陡增：修改其中一个接口时必须联动调整另一个。比如要修改Department的employees()返回类型，不仅要改接口定义，还得检查Employee接口里所有依赖Department的逻辑，甚至所有实现类都要同步调整，极易漏改引发bug。
• 丧失接口的独立复用性：接口本是用来实现解耦的契约，但循环依赖下，你没法单独把Employee接口抽出来用到其他模块，必须同时带上Department接口，反之亦然，完全破坏了接口的独立部署和复用价值。
• 传导至实现层的初始化问题：接口的循环依赖会让实现类也陷入循环依赖，比如EmployeeImpl实例化需要依赖DepartmentImpl，而DepartmentImpl初始化又需要EmployeeImpl，这在Spring等依赖注入框架中会直接触发循环依赖报错，手动初始化也容易出现空指针或逻辑混乱。
• 可读性差，上手门槛高：新开发者接手时，必须同时理清两个相互绑定的接口关系才能理解业务逻辑，不像单一职责的接口那样一目了然，很容易因理解偏差引入错误。

示例代码 #

// 员工接口，依赖部门接口
interface Employee {
    Department department();
    // 其他方法
}

// 部门接口，依赖员工接口
interface Department {
    Set<Employee> employees();
    // 其他方法
}

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