Doubts about the dependency between classes

Question one:

Usually in the design of the class when you often encounter the following situations, class A depends on Class B, and Class B is dependent on Class A, which will cause a cyclic dependency.
If there is a cyclic dependency in the class, it can result in a change in a that may affect B, and b if there is a change will also affect a (personal view).

In this process, I also abstracted a new Class C, which is used to store classes A and Class B interdependent parts, when a needs to call Class B, in this model can be directly called C. But at this point Class C is not going to rely on Class A and Class B, I think this is a difficulty, if you do not rely on the premise of Class B and Class A to complete the same logic as before (I think there will be a lot of duplicate code).

Q: are cyclic dependencies allowed during the design process? How to resolve circular dependencies?

Question two:
We usually use spring to write business logic when service a relies on service B and service C,service B to rely on service C. Every time I get obsessive-compulsive, I want to kill service B's dependence on service C. The service C is passed to service B directly by means of a reference in a

As shown above, it feels strange to call stacks when you use the spring framework as usual:

    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();        }    }    

such as the above code. I want to pass the result return value in a as a c.methodC() parameter B.methodB() , but this will cause one more parameter in the MethodB () method. The feeling is not particularly reasonable in design, because I feel that B.methodB() there is no need to perceive the existence of C when calling.

Q: How to use object-oriented perspective to understand the problem of the second scene.

Thank you

Reply content:

Question one:

Usually in the design of the class when you often encounter the following situations, class A depends on Class B, and Class B is dependent on Class A, which will cause a cyclic dependency.
If there is a cyclic dependency in the class, it can result in a change in a that may affect B, and b if there is a change will also affect a (personal view).

In this process, I also abstracted a new Class C, which is used to store classes A and Class B interdependent parts, when a needs to call Class B, in this model can be directly called C. But at this point Class C is not going to rely on Class A and Class B, I think this is a difficulty, if you do not rely on the premise of Class B and Class A to complete the same logic as before (I think there will be a lot of duplicate code).

Q: are cyclic dependencies allowed during the design process? How to resolve circular dependencies?

Question two:
We usually use spring to write business logic when service a relies on service B and service C,service B to rely on service C. Every time I get obsessive-compulsive, I want to kill service B's dependence on service C. The service C is passed to service B directly by means of a reference in a

As shown above, it feels strange to call stacks when you use the spring framework as usual:

    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();        }    }    

such as the above code. I want to pass the result return value in a as a c.methodC() parameter B.methodB() , but this will cause one more parameter in the MethodB () method. The feeling is not particularly reasonable in design, because I feel that B.methodB() there is no need to perceive the existence of C when calling.

Q: How to use object-oriented perspective to understand the problem of the second scene.

Thank you

1. Circular dependence is, of course, permissible, and there is no rule that reliance can only be one-way. Look at the patterns of intermediaries and observers in design patterns, which are typical cyclic dependencies. Take the observer pattern as an example: Subscribers rely on observers, and observers need to inform subscribers so they also rely on them.

2. Cannot do so. If the dependency design is not problematic, then a relies on B and C, and B relies on C instructions A and B do need c. If you kill the dependence of B on C as you say, then B has no need to exist, at which point B will degenerate to the "subordinate class" of a, or "Special method class" of a. That is, the reusability of B will be greatly discounted, if later there are other classes, such as D, also need to use B, then D will have to also rely on C, this will be the dependence of B and C dead, but D do not need C to work ah, just to "meet" B must first get a C, is it strange? (if D is exactly the same as a C, it's okay to say that D doesn't need C in itself)

So, first determine whether B really needs C, if the answer is yes, then do it with peace of mind.

1, interdependence is really a bad taste in the code, there is no better design scenario, can only try not to let this confusion spread to other classes.
2, for the layered design, I personally allow the same layer of the class interdependence, such as the existence of Service layer and DAO layer, the former depends on the latter, while the latter internal classes can also rely on each other, but never allow the DAO layer class call Service layer, once this will occur, This part of the logic should be placed on the Service layer.

