从编码风格的角度来看,循环类依赖是不是很糟糕？

Question

从编码风格的角度来看,循环类依赖是不是很糟糕？

例:

在数据库应用程序中,我们有两个类,一个封装有关单个数据库(DBInfo)的信息,另一个类可以创建数据库连接.(ConnFactory)

DBInfo具有getConnection其使用方法ConnFactory来创建连接.但是ConnFactory它本身需要一个DBInfo对象来做到这一点.

像这样:(为了便于阅读,忽略了任何编码风格)

class DBInfo {
    String name;
    String connectionUrl;

    Connection getConnection() {
        return ConnFactory.getConnection(this);
    } 
}


class ConnFactory {
    Connection getConnection(DBInfo toWhat) {
        return new Connection(toWhat.connectionUrl);
    }
}

我的同事认为这是不好的做法,如果只有一个依赖方向而没有像这里那样的循环方向会更好.

这是不好的做法,反模式还是代码味道？有什么缺点吗？

Answer 1

一般来说,我会将循环依赖称为Code Smell.请注意,"Code Smell"一词主要表示"这里是一段需要特别注意的代码,可能会受益于重新设计."

在大多数情况下,我会强烈考虑一种不需要循环依赖的设计,但在极少数情况下它可能没问题.

在您的示例中,ConnFactory似乎是多余的,但这可能是因为您的示例已被削减.但是,在我看来,如果它被移动到DBInfo类,那么Connection创建逻辑会更好.如果您已经有一个包含数据库数据的类,那么让它负责创建与该数据库的连接似乎很自然.

Answer 2

是的,一般来说循环依赖是坏的,虽然并不总是邪恶的.当一个模块中的更改传播到其他模块时,循环依赖性的问题包括紧耦合,相互依赖的模块以及通常的多米诺效应.

也就是说,您的代码违反了单一责任原则,因为DBInfo它不仅存储有关数据库的信息,还负责获取Connection对象.将该特定功能删除到单独的类中,一切都会很好.

Answer 3

不必要

我不认为类粒度级别的循环依赖是坏的.如果两个,三个或者四个类相互依赖,我没有看到问题.(我不是说这是你想要的东西,但在某些情况下它可以是好的).

如果您在程序包或模块级别具有相互依赖性,则出于上述和下面提到的所有原因,这是一个问题.