What is the definition of the term coupling?

Question

What is the meaning of the terms high/low coupling in object-oriented systems development or object-oriented programming (POO)?

Answer 1

Concept

• In a global aspect coupling is the degree of dependence between two "artifacts". Where artifacts can be entities, methods, component, tables, whatever is in the other.
• Low coupling - is when an "artifact" has little or no dependence on others.
• High coupling - is the reverse of the bass obviously, being when a "artifact" has a great dependence on another.

Good Practices (Design Principle)

• High coupling is not considered a good programming practice, where its components, "artifacts", will have a high degree of dependence, making it harder to maintain and test. *¹
• The low coupling is considered a good programming practice (Loose Coupling), since with it you keep your components, "artifacts", less dependent on each other, having greater traceability and testability. *¹

*¹ But this is only about Good Practices (design principle), it does not mean that you can not use high degree coupling in your project, because it is inevitable in some cases. Care should only be taken to maintain your design with the least degree of coupling possible.

Examples

• A common example of high coupling is inheritance, where your entity cannot exist without its base entity. In modeling this is considered the highest degree of coupling. But it should not leave to be used, should only be used with greater moderation, always analyzing whether this high degree of coupling.
• A good practice for reducing coupling is the use of other standards such as Dependency Injection (dependency Injection), which helps to reduce dependency between layers, entities or modules.
• To reduce coupling it is also advisable to analyze your dependencies, checking if they can be removed, or exchanged by another with a minor degree of dependency (for example, exchange a inheritance by an aggregation), this will already improve traceability and testability of your project.

Considerations

Coupling is necessary, between different modules, what the standards preach is that it is as small as possible, always assessing whether it is necessary to create a certain dependency or whether it can be replaced by a smaller dependency.

Obs.: The concept of coupling is independent of programming language or technology used in your project. It is a matter of good practice.

Answer 2

Coupling is how much one class knows of another class.

The ideal is that there is low coupling between classes because classes should be specialists for the service they have been designated.

Low coupling is also desired because it is easier to identify problems related to class, which is one of the principles of the object orientation paradigm.

EDIT

"Knowing of another class" means that the class in question uses methods and/or attributes of some other class. This makes the class dependent on the other class, that is, the class behavior will be directly linked to the behavior of the other.

The high coupling between classes makes it difficult to maintain them, because imagine, every time you edit a class you will also be changing the behavior of the classes that are coupled with it, if you are not aware of the coupled classes you will be running a great risk of being entering bugs and unexpected behaviors to your program.

Answer 3

They talked so much about the definition, I’ll talk a little bit about Weak coupling:

Introducing

Weak coupling is one of the main requirements for building quality object-oriented (OO) software. The weak coupling measures how much a class depends on, or is related to, another class or subsystem. The ability of one class to inherit the behavior of another(s) is one of the main features of the OO paradigm. The main advantage is to be able to create new classes almost for free, taking advantage of the code of another. This article discusses these two concepts and shows why inheritance, in general, helps compromise weak coupling.

Weak coupling

A class with strong coupling relies heavily (usually without need) on others. This can lead to the following problems [Larman]:

classes that are difficult to take advantage of, since whenever this class is used all the others on which it depends must be present;

changes in related classes may force local changes and

are difficult to understand in isolation.

Common forms of coupling occur through: instance variables, local variables to methods or their arguments, called services in another class, one class derives directly or indirectly from another or one class implements a particular interface. In short, whenever a class references another type in any of the above circumstances coupling is occurring. Consider the code:

public class X
{
    private ClasseConcretaY var1;
void M1(ClasseConcretaW var2 ) { … }
}

There are two main coupling points, in the instance variable var1, which is of the Classeconcretay type, and in the argument var2, which is of the Classeconcretaw type. In these two parts of the code the class X references two other concrete classes. This means that whenever this class is used, the other two must be available in the program namespace. In the case of Java, the(s) package(s) where they are located should(or) be in the classpath.

But, does referencing other classes always cause coupling problems? The answer is, it depends! Referencing stable and widespread classes is rarely a problem. For example, using the java.util package in a Java program will hardly cause future docking problems, since any Java runtime environment contains this library. The problem is in unstable classes, little known, ie in the classes that are created to meet the specific problems of projects.

How to decrease coupling?

A general rule of thumb for reducing coupling is "programming to an interface and not to an implementation" [Gamma]. In the above example this means replacing the statements of the concrete classes with statements of interfaces. Doing this decouples the code from a specific implementation, making it dependent only on an interface. This is not the definitive solution, a good project with good responsibilities is crucial, but it helps a lot. It is easier to understand alone a class that references only interfaces and more [Gamma]:

customers (class users) remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that customers expect, clients remain unaware of the classes that implement these objects; they only have knowledge of the abstract classes that define the interface.

Source: http://www.devmedia.com.br/acoplamento-fraco-x-heranca/3714