Brief analysis of cohesion-poly low coupling

Cohesion is the measurement of the connection within the module from a functional point of view, and a good cohesive module should do exactly one thing.  It describes the functional linkages within the module, which is a measure of the connection between modules in the software architecture, and the coupling strength depends on the complexity of the interface between the modules, the points entering or accessing a module, and data passing through the interface. Cohesion is the degree to which each element in a module is tightly bound to each other, and high cohesion is a module in which each element is tightly bound to each other. The so-called high cohesion refers to a software module is composed of strong correlation code, only responsible for a task, that is, the single principle of responsibility is often said. Coupling: A measure of the degree of interconnection between different modules within a software structure (coupling is also called block-to-chunk linkage.) A measure of the degree of connection between modules in a software system structure. The tighter the connection between the modules, the stronger the coupling, the less the independence of the module, and the coupling between the modules depends on the complexity of the interface between the modules, the mode of invocation and the information transmitted. For low-coupling, the superficial understanding is: a complete system, between the module and the module, as far as possible to make its independent existence. In other words, let each module, as far as possible, complete a specific sub-function independently. The interface between modules and modules is as small and simple as possible. If the relationship between the two modules is more complex, it is better to consider the further module division first. This facilitates modification and combination. [1]

Simple generalization: Coupling is the relationship between part of a program and other parts. Decoupling is the need to straighten out the necessary coupling, while minimizing unnecessary coupling (this sentence is actually cohesion low-coupling of the popular interpretation).

How you look at coupling depends on what perspective and level you are looking at a program. If you are looking at a function or an internal implementation of a class, this granularity is fine. This time you may be concerned about how to write a function/class beautifully, so that it is functional and easy to understand at the same time. You can improve it by improving the layout of the code, optimizing the algorithm, encapsulating the repetitive action as a new function, giving a variable or function a more meaningful name, and so on.

These methods can be said to be related to "high cohesion and low coupling". Improve code layout: Make your code more code-like, making it easier for people to see the meaning and intent of each code. Proper name: If you give a variable a name called variable, it can be semantically stored with arbitrary values, its ambiguous name makes it difficult to distinguish it from other code (and other parts have unnecessary coupling), which will make reading the code of the people at a loss. Making a variable name more meaningful is actually a manifestation of high cohesion, which is what you want it to be, and others can see it at a glance. The extraction function is not to mention.

If you are designing a module, you may be interested in the classes and objects in the module, that is, how to make the relationships between classes and objects in the module simpler and clearer. Gang of Four's "design Model" This book is mainly about this, each of which is to find ways to reduce the coupling between classes and objects.

So if you're designing a system, you probably don't care about the class (at least not at first), you should focus on how the system can be divided into several modules, how each module is grouped together (the term "collaboration") to make up the whole system. If you design a module that also focuses on the implementation details of other modules, your system will fail.

Therefore, regardless of your angle, the level of attention, reduce complexity is necessary. This is the core concept of coupling and decoupling.

It is said that any metaphor is lame, but I would like to cite an example of the extremely efficient and low coupling in reality, the army. A country's army is less than tens of thousands of people, more than millions of people, such a large system, its efficiency is surprisingly high. Why? In short, this is due to several principles of its actions:

Strict discipline, curried
Will not appear in the superior issued an order after the person can not find the execution, or find people but do not want to do embarrassing situation (very much wood has)

command does not span levels
Unless special circumstances, otherwise the command is communicated through the direct superior, the commander will seldom find the soldiers alone (each level in the upper level seems to be high cohesion, at the same time, the Commander, Monitor, head of these leaders as an interface of this level, the upper level only through the interface to send commands to subordinate)
It is said that if the commander directly find the soldiers to do things to him is not more efficient than the first level of communication? No! Why? There are several reasons for this (note that we can relate to the logic of our programming, so that everything is figured out)

1. The command issued by the commander is usually a great task, often to cross a lot of troops and even classes, if the commander of a notice is not to be exhausted? (High-level abstraction should not be directly coupled to the underlying implementation)

2. If arbitrary cross-level commands are allowed, it is likely that multiple superiors will give different orders to a soldier at the same time, and the soldier is not exhausted. (resulting in inconsistent system State, or a distributed system of busy and busy conditions)

3. Communication between soldiers and direct superiors is usually barrier-free, but cross-level is hard to say. What soldier is good at doing something only his direct superiors are most aware that cross-level commands can lead to inefficient task completion, or even the consequences of task failure (high-level abstractions tend to be difficult to master the underlying details, leading to improper use and even misuse)

Clear delineation of functions
Troops will be divided by region, time domain, department, class, etc. to divide the responsibility of the entire force, so that a layer, a piece of the whole unit into a clear responsibility of a small part of the relative independence of the various parts is an organic whole, so it is difficult to think of efficient.

Certain modules must be associated to work, which is determined by the business logic and cannot be denied. So decoupling is not a literal gatekeeper, but the connection between modules is relaxed to the extent necessary. Some suggestions:

• The module only exposes minimal interfaces to the outside, forming the lowest dependency relationship.
• As long as the external interface is unchanged, the internal modification of the module shall not affect the other modules;
• Deleting a module should only affect other modules that have dependencies, and should not affect other unrelated parts;

Software Engineering has an iron law "high cohesion, low coupling" is the truth: the necessary coupling is undeniable, no coupling program does not work, but the unnecessary tight coupling, will let the program "reaching", eventually let the programmer's writing and maintenance can not be done.

Humans can only focus on a fraction of the content at a time. "High cohesion, low coupling" is to meet the human characteristics of this-small scale only focus on a module, local coding work can be carried out. The large-scale transformation of specific code into some abstract "module" and "dependency relationship", can grasp the large and small, grasp the process of the program, put together a complete product.

Imagine the "social division of Labor" model--each small unit focuses only on its own business segments, with other organizations that have only business outsourcing links, and material and information interactions. The fact has proved that this model than the previous large state-owned enterprises "embracing" self-management of various functional departments of efficiency, a level of improvement. This is the embodiment of "high cohesion, low coupling" in the real world.

The program is the second world created by mankind, the logic of the program is nothing more than the abstraction of the world Operation Law. Out of the program to see the program, you will find different views and angles.

Brief analysis of cohesion-poly low coupling