Questions about the dependency between classes

Problem 1: when designing A Class, Class A is usually dependent on class B and class B is dependent on Class A, which leads to circular dependency. If there is A circular dependency in the class, it will lead to A change that may affect B, and if B is changed, it will also affect A (personal opinion ). Here...Question 1:

When designing A class, you will often encounter the following situations: Class A depends on Class B, and Class B also depends on Class A, which will cause circular dependency.
If there is A circular dependency in the class, it will lead to A. If A is changed, it may affect B. If B is changed, it will also affect.(Personal opinion ).

In this process, I abstracted A new class C, which is used to store the interdependent parts of Class A and Class B. When Class A needs to call class B, in this model, you can call C directly. However, Class C does not depend on Class A and Class B at this time. I think this is A difficult issue. If it is not dependent on class B and class, complete the same logic before (here I think there will be a lot of repeated code ).

Q: Are circular dependencies allowed during the design process? How to solve the circular dependency?

Question 2:
When we use spring to write business logic, Service A depends on Service B and Service C, and Service B depends on Service C. At this time, I have obsessive-compulsive disorder. I want to eliminate Service B's dependency on Service C. In A, Service C is directly transmitted to Service B by passing parameters.

As shown above, some call stacks may be strange when spring framework is used at ordinary times:

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

The above Code. At this time, I wantc.methodC()The Return Value of the result is passedB.methodB()But this will cause a parameter to be added to the methodB () method. I feel that it is not particularly reasonable in design, because I think it isB.methodB()In this case, you do not need to perceive the existence of C.

Q: How can I understand Question 2 from an object-oriented perspective.

Thank you.

Reply content:Question 1:

When designing A class, you will often encounter the following situations: Class A depends on Class B, and Class B also depends on Class A, which will cause circular dependency.
If there is A circular dependency in the class, it will lead to A. If A is changed, it may affect B. If B is changed, it will also affect.(Personal opinion ).

In this process, I abstracted A new class C, which is used to store the interdependent parts of Class A and Class B. When Class A needs to call class B, in this model, you can call C directly. However, Class C does not depend on Class A and Class B at this time. I think this is A difficult issue. If it is not dependent on class B and class, complete the same logic before (here I think there will be a lot of repeated code ).

Q: Are circular dependencies allowed during the design process? How to solve the circular dependency?

Question 2:
When we use spring to write business logic, Service A depends on Service B and Service C, and Service B depends on Service C. At this time, I have obsessive-compulsive disorder. I want to eliminate Service B's dependency on Service C. In A, Service C is directly transmitted to Service B by passing parameters.

As shown above, some call stacks may be strange when spring framework is used at ordinary times:

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

The above Code. At this time, I wantc.methodC()The Return Value of the result is passedB.methodB()But this will cause a parameter to be added to the methodB () method. I feel that it is not particularly reasonable in design, because I think it isB.methodB()In this case, you do not need to perceive the existence of C.

Q: How can I understand Question 2 from an object-oriented perspective.

Thank you.

1. Circular dependency is of course allowed. There is no rule that dependency can only be one-way. Look at the mediation and observer patterns in the design pattern. They are typical circular dependencies. Taking the observer mode as an example: the subscriber will depend on the observer. The observer must notify the subscriber so it also depends on them.

2. You cannot do this. If there is no problem with dependency design, then A depends on B, C, and B to indicate that A and B really need C. If B's dependency on C is eliminated as you said, then B has no need to exist. At this time, B will degrade to A's "ancillary class ", or is A "special method class" of ". That is to say, the reusability of B will be greatly reduced. If other classes such as D and B need to be used in the future, D will have to depend on C, this binds the dependency on B and C, but D may not need C to work. Just to "satisfy" B, A C must be created first. Isn't it strange? (If D is the same as A, it does need C. Here we will talk about the situation where D itself does not need C)

Therefore, first determine whether B really needs C. If the answer is yes, do it with peace of mind.

1. mutual dependency is indeed a tangle of bad taste in the Code. If there is no better design scheme, we can only try not to spread this confusion to other classes.
2. for hierarchical design, I personally allow the classes on the same layer to depend on each other. For example, there are Service and DAO layers. The former depends on the latter, the classes in the latter can also be dependent on each other, but the classes in the DAO layer are never allowed to call the Service layer. Once such a willingness occurs, this part of logic should have been placed on the Service layer.