Question about External Coupling

[Bencotti]

From the textbook,

External coupling: two modules share an externally imposed convention e.g., data formats, communication protocols, device interfaces.

Is it right of me to assume that in this scenario, A and B are both coupled to each other? Or are the modules coupled to the imposed convention instead?

The later explanation seems to fit with this source's resolution for external coupling

External coupling can be resolved by eliminating the knowledge of formats from the domain, and operating on concepts.

[brandoncjh]

I feel that it refers to the latter as well.

https://www.youtube.com/watch?v=XQnytAeZrWE#t=16m15s In the diagram that he draws, he describes the function calls to the OS as the external couplings rather than between different functions. So a change in 1 function call wouldn't necessarily affect the other function call couplings, whereas if they changed the OS all the function call couplings would have to change as well.

[dejunnn]

I have a related question regarding coupling. If I have multiple classes utilising the same static class, is that considered high coupling? For example, multiple command classes utilising methods from a static class.

Alternatively, what if those multiple classes are utilising methods from another class (an instantiated object)? For example, multiple command classes utilising methods from an object passed in as a parameter.

Is there a difference if the class is static or not?

[damithc]

Is it right of me to assume that in this scenario, A and B are both coupled to each other? Or are the modules coupled to the imposed convention instead?

Don't worry so much about the direction. What matters to us is that, because A and B both deal with the same external component, when you modify A, there is a chance that you need to modify B (and vice versa), for example, if the change in A was due to a change in the external component and that change affects how B interacts with the external component as well. That kind of ripple effect is what we are looking out for.

I have a related question regarding coupling. If I have multiple classes utilising the same static class, is that considered high coupling? For example, multiple command classes utilising methods from a static class.

Every dependency is a coupling. The case of many components depending on another single component is not so much a matter of high or low coupling but it is indeed a design decision with pros and cons. One pro is that a component being reused a lot, and reuse is generally a good thing. One con is that it becomes a single point of failure. Splitting the class into multiple classes will distribute some of those couplings but again, whether to split, and in what way to split, are design decisions with pros and cons, and depend on the context.

Alternatively, what if those multiple classes are utilising methods from another class (an instantiated object)? For example, multiple command classes utilising methods from an object passed in as a parameter.

In this case we are comparing class-level vs instance-level members. The main difference between the two is class-level members are shared between all callers. If you want to maintain a shared state, class-level members provide an easy way to do that, without having to pass an object (containing the shared state) around. One con of Java static methods is that they cannot be overridden by sub-classes (i.e., not possible to take advantage of polymorphism).