Definition: One object should keep the least understanding of other objects.
The origin of the problem: the relationship between classes is getting closer and closer, and the coupling is getting greater and greater. When one class changes, the greater the impact on another class.
Solution: Minimize coupling between classes as much as possible.
Since we came into contact with programming, we have known the general principles of software design, low coupling and high cohesion. Whether it is object-oriented or process-oriented, the coupling degree should be as low as possible to improve the reuse rate of code. But how to program low coupling?
No matter how complex the logic is, for dependent classes, try to encapsulate the logic inside the class, and do not disclose any information to the outside except for the public methods provided. There is also a simpler definition: only communicate with direct friends. First, let’s explain what a direct friend is; each object will be coupled with other objects. Let’s say that there is a coupling relationship between these two objects. Let’s say that these two objects have a friend relationship. There are many ways in which coupling occurs, such as dependency, association, composition, aggregation, etc. Among them, we call the class that appears member variables, method parameters, and method return values called direct friends, while the class that appears in local variables is not direct friends. That is to say, it is best not to appear inside the class as local variables;
For example, in a school, there are several teachers in it, numbered in sequence. There are several students below, numbered at one time. Now ask to print out all teachers and students' IDs.
First, violate the principle of low coupling and high cohesion
The code is as follows.
package test1;import java.util.ArrayList;import java.util.List;class Teacher{privateString id;publicvoidsetId(String id) {this.id=id;}publicString getId() {return id;}}class Student{private String id;public void setId(String id) {this.id=id;}public String getId() {return id;}}class StudentManage{publicList<Student> getAllStudent() {List<Student> list=newArrayList<Student>();for (int i=0;i<100;i++) {Student student=new Student();student.setId("Student student number is"+i);list.add(student);}return list;}}class TeacherManage{publicList<Teacher> getAllTeacher() {List<Teacher> list=newArrayList<Teacher>();for (inti=0;i<100;i++) {Teacher teacher =new Teacher();teacher.setId("Teacher number"+i);list.add(teacher);}return list;}public void printAllPerson(StudentManagestudentmanager) {List<Student>list1=studentmanager.getAllStudent();for (Student s:list1) {System.out.println(s.getId());}List<Teacher>list2=this.getAllTeacher();for (Teacher t:list2) {System.out.println(t.getId());}}} public classClient {publicstaticvoidmain(String[] args) {TeacherManagetm=newTeacherManage();tm.printAllPerson(new StudentManage());}} The main problem of this design now appears in the TeacherManage class. According to the low coupling and high cohesion law, it only communicates with direct friends. The Student class is not a direct friend in the TeacherManage class. Such non-direct friend relationship coupling should be avoided in the class.
After modification, the code is as follows:
package test2;import java.util.ArrayList;import java.util.List;class Teacher{privateString id;publicvoidsetId(String id) {this.id=id;}publicString getId() {return id;}}class Student{private String id;public void setId(String id) {this.id=id;}public String getId() {return id;}}class StudentManage{publicList<Student> getAllStudent() {List<Student> list=newArrayList<Student>();for (int i=0;i<100;i++) {Student student=new Student();student.setId("Student number is"+i);list.add(student);}return list;}public void printAllStudent() {List<Student>list1=this.getAllStudent();for (Student s:list1) {System.out.println(s.getId());}}}class TeacherManage{publicList<Teacher> getAllTeacher() {List<Teacher> list=newArrayList<Teacher>();for (inti=0;i<100;i++) {Teacher teacher =new Teacher();teacher.setId("Teacher number"+i);list.add(teacher);}return list;}publicvoidprintAllTeacher() {List<Teacher> list2=this.getAllTeacher();for (Teacher t:list2) {System.out.println(t.getId());}}}public classClient {publicstaticvoidmain(String[] args) {TeacherManagetm=newTeacherManage();tm.printAllTeacher();StudentManagesm=newStudentManage();sm.printAllStudent();}}After the modification, the student has added a new method of student ID and the teacher can call it directly. This avoids coupling with students. The original intention of the principle of low coupling and high cohesion is to reduce the coupling between classes. Since each class reduces unnecessary dependencies, it is indeed possible to reduce the coupling relationship. However, everything has a degree. Although communication with indirect classes can be avoided, in order to communicate, relationships will inevitably occur through an "intermediary". Using this rule can achieve clear structure, high cohesion and low coupling,
Coupling and cohesion are two qualitative standards for module independence. When dividing software systems into modules, try to achieve high cohesion and low coupling as much as possible to improve the independence of the module, and lay the foundation for designing high-quality software structures.
There is an example that is easy to understand: a program has 50 functions, and this program executes very well; however, once you modify one of the functions, the other 49 functions need to be modified, which is the consequence of high coupling.
Summarize
The above is all the content of this article about the code analysis of the example code of high cohesion and low coupling law. I hope it will be helpful to everyone. Interested friends can continue to refer to other related topics on this site. If there are any shortcomings, please leave a message to point it out. Thank you friends for your support for this site!