从编码风格的角度来看，循环类依赖是不好的吗？
从编码风格的角度来看，循环类依赖是不好的吗？
示例：
在数据库应用程序中，我们有两个类，一个封装有关单个数据库(DBInfo)的信息，另一个类可以创建数据库连接。(ConnFactory)
DBInfo有一个使用ConnFactory创建连接的getConnection方法。但是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);
}
}我的同事认为这是糟糕的做法，如果只有一个方向的依赖关系，而不是像这里这样的循环方向，那会更好。
这是一种糟糕的实践，是反模式还是代码气味？有什么缺点吗？
回答 7
Stack Overflow用户
发布于 2009-08-31 08:02:09
一般而言，我将循环依赖称为代码气味。请注意，术语“代码气味”主要表示“这是一段需要特别注意的代码，很可能会从重新设计中受益。”
在大多数情况下，我会强烈考虑不需要循环依赖的设计，但在极少数情况下，它可能是可以的。
在您的示例中，ConnFactory似乎是多余的，但这可能是因为您的示例被删减了。但是，在我看来，如果将连接创建逻辑移到DBInfo类中会更好。当您已经有一个包含有关数据库的数据的类时，让它负责创建到该数据库的连接似乎是很自然的事情。
Stack Overflow用户
发布于 2009-08-31 07:56:55
是的，一般来说，循环依赖是不好的，尽管并不总是坏事。循环依赖的问题包括紧密耦合、相互依赖的模块，以及当一个模块中的更改传播到其他模块时通常会产生的骨牌效应。
也就是说，您的代码违反了单一责任原则，因为DBInfo不仅存储有关数据库的信息，而且还负责获取Connection对象。把这个特定的功能移到一个单独的类中，一切都会很好。
Stack Overflow用户
发布于 2009-08-31 08:53:12
不一定是
我不认为类粒度级别的循环依赖是不好的。如果两个、三个或四个类相互依赖，我看不出有什么问题。(我并不是说这是你想要的，但在某些情况下是可以的)。
由于上面和下面提到的所有原因，如果您在包或模块级别上存在相互依赖，则It 将是一个问题。
https://stackoverflow.com/questions/1356304
复制相似问题