Heim >Backend-Entwicklung >PHP-Tutorial >关于类之间的依赖关系的疑惑
平时在设计类的时候往往会遇到以下情况,类A依赖于类B,同时类B又依赖于类A,这样就会造成循环依赖。
如果在类中存在循环依赖,就会导致,如果A中有改变可能会影响B,同时B如果有变化也会影响A(个人观点)。
在这个过程中,我又抽象出一个新的类C,这个类用来存放类A和类B相互依赖的部分,当A需要调用类B,在这个模型中可以直接去调用C。但是此时类C是不会去依赖类A和类B,我觉得这是一个难点,如果在不依赖类B和类A的前提下,完成以前一样的逻辑(这里我认为会存在很多重复的代码)。
Q:在设计过程中,循环依赖是否是允许的?如何解决循环依赖?
问题二:
平时我们在用spring写业务逻辑的时候,当Service A依赖Service B和Service C,Service B依赖Service C。每当这个时候我就会有强迫症,我想把Service B 对Service C的依赖干掉。在A中直接通过传参的方式把Service C传给Service B
如上所示,感觉在平时用spring框架的时候一些调用栈会很奇怪:
<code> public class A{ private C c; private B b; public void methodA(){ c.methodC(); b.methodB(); } } public class B{ private C c; public void methodB(){ c.methodC(); doSomething(); } } </code>
如上代码.每当这个时候我都想把在A中c.methodC()
的结果返回值通过参数传给B.methodB()
,但是这样会导致methodB()方法中多了一个参数。感觉在设计上又不是特别合理,因为我觉得在调用B.methodB()
的时候是不需要感知C的存在的。
Q:怎么用面向对象的角度去理解问题二这个场景。
谢谢
平时在设计类的时候往往会遇到以下情况,类A依赖于类B,同时类B又依赖于类A,这样就会造成循环依赖。
如果在类中存在循环依赖,就会导致,如果A中有改变可能会影响B,同时B如果有变化也会影响A(个人观点)。
在这个过程中,我又抽象出一个新的类C,这个类用来存放类A和类B相互依赖的部分,当A需要调用类B,在这个模型中可以直接去调用C。但是此时类C是不会去依赖类A和类B,我觉得这是一个难点,如果在不依赖类B和类A的前提下,完成以前一样的逻辑(这里我认为会存在很多重复的代码)。
Q:在设计过程中,循环依赖是否是允许的?如何解决循环依赖?
问题二:
平时我们在用spring写业务逻辑的时候,当Service A依赖Service B和Service C,Service B依赖Service C。每当这个时候我就会有强迫症,我想把Service B 对Service C的依赖干掉。在A中直接通过传参的方式把Service C传给Service B
如上所示,感觉在平时用spring框架的时候一些调用栈会很奇怪:
<code> public class A{ private C c; private B b; public void methodA(){ c.methodC(); b.methodB(); } } public class B{ private C c; public void methodB(){ c.methodC(); doSomething(); } } </code>
如上代码.每当这个时候我都想把在A中c.methodC()
的结果返回值通过参数传给B.methodB()
,但是这样会导致methodB()方法中多了一个参数。感觉在设计上又不是特别合理,因为我觉得在调用B.methodB()
的时候是不需要感知C的存在的。
Q:怎么用面向对象的角度去理解问题二这个场景。
谢谢
循环依赖当然是允许的,没有任何规定说依赖只能是单向的。看看设计模式中的中介者、观察者等模式,它们就是典型的循环依赖关系。以观察者模式为例:订阅者会依赖观察者,观察者需要通知订阅者所以也要依赖它们。
不能这样做。如果不是依赖关系设计有问题,那么A依赖B和C、B依赖C说明A和B确实需要C。如果像你说的那样把B对C的依赖干掉,那么B就没有存在的必要了,此时B将退化为A的“附属类”,或者说是A的“专用方法类”。也就是说,B的可复用性就会大打折扣,如果以后有其他类,比如D,也需要用到B的话,那么D将不得不也依赖C,这就把对B和C的依赖绑死了,但D未必需要C才能干活啊,仅仅是为了“满足”B就必须先弄一个C,是不是很奇怪?(如果D跟A一样确实也需要C那是可以的,这里说的是D本身不需要C的情况)
所以,首先确定B是否确实需要C,如果答案是肯定的,那就安心地这么干吧。
1、相互依赖确实是代码中让人纠结的坏味道,没有更好的设计方案的情况下,只能尽量不让这种混乱扩散到其他类。
2、对于分层设计,我个人是允许同一层的类之间相互依赖的,比如存在 Service 层和 DAO 层,前者依赖后者,而后者内部的类也可以相互依赖,但绝不允许 DAO 层的类调用 Service 层,一旦出现这种意愿,说明这部分逻辑本来就应该放在 Service 层。