What is Class Coupling?

Question

I was reading this reply in relation to the design standards relating to Serviceprovider and Servicecontainer, however, the AR Euler01 cited a pattern that mentions class coupling, and it was at this point that I was left with a question.

This term:

Coupling between Classes

---

Doubts

I’d like to know what class coupling is?

^{If possible, I would like examples of illustration in PHP or C#, but feel free to give examples in other languages.}

Answer 1

In software engineering, coupling is a metric that defines the degree of inter-dependence between the elements of a module. We could summarize in one word: Dependency, that is, coupling is the degree of dependency in which an artifact relates to another, consider an artifact as any "thing" that is part of the final product in the development environment (A framework, an object, a class, etc.). In class context, coupling refers to how different classes connect to each other.

Weak or low coupling: the components of a system are interconnected so that one depends on the other as little as possible.

Strong or high coupling: The components are interconnected in such a dependent way that it is practically impossible to alter one of them without causing side effects in all or a large part of the system.

Strongly coupled classes contains a large number of interactions and dependencies, while in classes with weak coupling, the opposite occurs, where dependencies between classes are solved through well-defined public interfaces, reducing direct dependencies as much as possible.

One of the developers of the defunct SUN, in a forum, posted the following text (slightly adapted to the context of this response) in a discussion about coupling:

Legos, those fitting toys, would be considered weakly coupled, because you could just piece together and build any system you want. However a puzzle has parts that are heavily engaged. You can’t catch a piece of a puzzle (system) and fit it into a puzzle different, because the system (puzzle) is very dependent on parts that were built specifically for that design particular. The Egos are constructed in a more generic way of shape that allows you to build a house with the same pieces I can build a car.

It is practically impossible to develop software without any coupling, but it is desirable that the coupling be as weak as possible.

I will give an example in python because it is the language that I am involved in at the moment, of course this example presents an absurdity only to highlight the problem of coupling.

class A:
    def get_hello():
        b = B
        return b

class B:
    def hello():
        print ('Hello World!')            

>>>> A.get_hello().hello()                   
>>>> Hello World!           

Note that to execute hello() is called a method of an object returned by another method, the hello() method is called by the get_hello() method, this is bad because it increases the coupling between classes making it difficult to maintain, once one of them is replaced or refactored pay the price of side effects.

In the context of python it is possible to elucidate a little more in this example:

def func(obj):
    obj.method1()  # Ok
    obj.method1().method2() # Bad

In this example, the parameter passed is an object that has a method (method1), which, in turn, has a second method embedded, depending on this call in this class is that it configures the coupling problem.

A good practice for a developer when building a class is to ask: I am conceiving something more like lego o with a puzzle?

As mentioned in the comments, I suggest that you also study the concept of cohesion. Coupling refers to how artifacts relate to each other and cohesion refers to how the internal components of an artifact relate to each other.

The greater the cohesion, the lower the coupling level and the better the software design.