What is the definition of the term coupling?

Concept

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

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. * ¹
• Low coupling is considered a good programming practice (loose coupling), since with it you keep your components, "artifacts", less dependent on one another, with greater traceability and testability. * ¹

  

* ¹ But this is just good practice (design principle), not to say that you can not use high-grade coupling in your project, because it is inevitable in some cases. One should only take care to keep your design as low as possible.

Examples

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

Considerations

The coupling is necessary, between different modules, what the standards preach is that it is the smallest possible, always evaluating if it is necessary to create a certain dependency or if it can be replaced by a smaller dependency.

  

Note: The concept of coupling is independent of the programming language or technology used in your project. It's about good practices .

Coupling is how much a class knows of another class.

Ideally, there should be low coupling between classes because classes should be experts for the service they were assigned to.

Low coupling is also desired as it becomes easier to identify class-related problems, which is one of the principles of the object-oriented paradigm.

EDIT

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

They talked so much about the definition, so I'll talk a bit about weak coupling:

Introduction

Poor coupling is one of the key 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 a class to inherit the behavior of another (s) is one of the main characteristics of the OO paradigm. The main advantage is being able to create new classes almost for free, taking advantage of another's code. This article discusses these two concepts and shows why inheritance generally helps to compromise weak coupling.

Poor coupling

A class with strong coupling depends a lot (often unnecessarily) on others. This can lead to the following problems [Larman]:

· classes that are difficult to take advantage of, since every time it is used all the others it depends on must be present;

· changes in related classes can 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, calling services in another class, one class derives directly or indirectly from another or a class implements a given interface. In short, whenever a class references another type in any of the above conditions 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 type ClassConcretaY, and in the argument var2, which is of type ClassConcretaW. In these two parts of the code the class X refers to two other concrete classes. This means that whenever this class is used, the other two should be available in the program namespace. In case of Java, the package (s) where they are should be in the classpath.

But referencing other classes always causes 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 coupling problems, since any Java runtime environment contains this library. The problem is in unstable, unrecognized classes, that is, in classes that are designed to address the specific problems of the projects.

How to decrease the coupling?

A general rule to decrease the coupling is to "program for an interface and not for an implementation" [Gamma]. In the example above this means replacing the declarations of the concrete classes with declarations of interfaces. Doing so 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 attributions of responsibilities is crucial, but it helps a lot. It is easier to understand a class in isolation than just interfaces and more [Gamma]:

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

Source: link