To understand what Low Coupling and High Cohesion are, you need to understand what the words Coupling and Cohesion actually mean. Coupling is the focus on the complexity between itself and other classes, while Cohesion focuses on the complexity within its own class. With this understanding of the terms Coupling and Cohesion, we can now explore the principles associated with these terms.
Low Coupling:
When you are creating a new class, you want your written code to have only the necessary number of relationships with other classes. This is critical, as any relationship exceeding the required amount results in written code with unnecessary relationships or “clutter” that will become problematic when the code-writer goes about debugging the code or having to maintain it. This is because the relationship between the classes within a string of written code or “ribbon of code” are all mutually dependent on the other classes within the “ribbon”.
High Cohesion:
When creating a new class, you want your class to perform just a single task and nothing else or, have a very clear purpose of what it’s goals are. The reasoning for adhering to this principle is that it limits the responsibility of every class; it ensures that every class is only responsible for its own tasks and does not perform any unnecessary work.
Summary: Knowledge Check of Low Coupling/High Cohesion
Low Coupling and High Cohesion are very similar in that they both deal with classes that only perform their specific tasks and are not dependent on other classes to carry out their specific role. A good quote that sums up the benefits of the two related principles is, “If a class is so highly coupled or lacking in cohesion as to make a design brittle or difficult to modify, then apply other appropriate GRASP patterns to reassign the class’s responsibilities.”(Grand).
Low Coupling/High Cohesion examples:
If you are creating a baseball game program, you would not want a class made up exclusively of baseball players performing the tasks (e.g. cutting the grass, working the ticket booth or selling hot dogs, soda & popcorn) that are the responsibility of a class comprised solely of the non-player personnel & staff of the baseball organization. Simply put, while the two classes have their own unique responsibilities, they have a mutual relationship, as baseball stadiums are where the baseball games are held and players participate in those games.
Information Expert:
Turning now to the Information Expert principle. You use the Information Expert principle in the designing stage while you are creating the architecture of the product. The idea is that you are looking at the list of tasks you would like your product to be able to accomplish and figure out where you need to delegate the responsibilities of the tasks to the appropriate classes.
An example of the Information Expert Principle:
If your end product, or desired result, was to design a web application of a checkers game, here are three sample classes that you would have:
If your task was to add the functionality of changing the player’s name, you would look at the different classes that you have and figure out which class is the most appropriate class to add that functionality to. In the case at hand, it would make the most sense to add this functionality to the class comprised of the baseball players.
The end benefits of the Information Expert principle is that you are following/adhering to the High Cohesion Principle without even realizing it and it’s helping you keep your codebase be more organized.
Footnote:
Image source link
I made the UML diagram
Grand, Mark. Patterns in Java. 2nd ed. 2 vols. Hoboken, NJ: Wiley, 1999.
The principles/ideas That Govern Software 