Making Good Software

In my opinion coupling is a very dangerous metric, is something desirable, but if it drives the architecture, it will make your project over complicated, to try to prove my point I am going to start from the basics.

In object oriented programming, coupling refers on how strongly linked are two objects that need to talk to each other.

The degree of coupling is important because, given a change in one of the components, the chances of having to change the other linked object, is proportional to the degree of coupling. When talking about coupling, objects are considered loosely coupled when they are designed so that a change in one object doesn’t require the other object to change.

Loose coupling is one of the most desired qualities in modern software development, but because its very subjective nature, and because the lack of analysis on the different types of coupling, some wrong decisions may be taken in the architecture just for the sake of making the application more loosely coupled.

Considering “the looser the architecture, the better”, is wrong, for each two objects that need to be coupled, their circumstances should be analyzed and based on these circumstances, the most appropriate type of coupling should be used.

Types of coupling.

Direct coupling.

Direct coupling happens when the two objects that need to be linked, talk to each other directly.

From a hardware point of view, this coupling always happens between two objects from the same application which are sitting in the same shared memory area.

Direct coupling is the simplest coupling to implement, but is the one with the highest level of coupling. A change on any of the linked objects is very likely to cause a change in the other object.

There are two styles of direct coupling. Black box coupling and White box coupling.

• Black box coupling is a style of direct coupling where the link between the two objects is created without revealing any implementation detail. The most common form of black box coupling is when object A calls directly a public method in object B.
• White box coupling is a style of direct coupling where the link between the objects carries some implementation information. The most common form of white box coupling is when object A access directly a member variable of the object B. White box coupling is discouraged because it creates even higher coupling than black box coupling and the complexity and effort remains the same.

Indirect coupling.

Indirect coupling uses a third, or more elements, to couple the two objects that need to talk to each other. The purpose of adding additional layers between the two components is so that even if one of the linked objects change, the intermediary doesn’t, or if it does, it changes internally so from the other linked object perspective everything remains the same.

Indirect coupling adds complexity to your application but it offers the loosest coupling.

Indirect coupling can be classified depending on

1. Location of the components.
• In memory. The two objects that need to be linked are part of the same application and are loaded at the same time in memory.
• Remote. The two objects are part of different applications, so they don’t share the memory space. Remote coupling adds complexity but is considered to have a lower coupling than in memory coupling
2. Synchronicity.
   • Synchronous coupling. The standard indirect coupling.
   • Asynchronous coupling. Also known as fire and forget, if asynchronous coupling is required, the complexity of the application would be higher, but it will be likely to have a lower coupling.

Conclusion.

The main conclusion is: The lowest is the coupling, the highest is the complexity. The “Oh yeah! Let’s just take a loose coupling approach”, doesn’t work. What is really important in your design, is how simple it is, so it should be prioritized the simplest approach as possible, which, funny enough, will probably carry a higher coupling.

The degree of coupling should be dictated by the requirements, and the simplest approach should be preferred.

Related posts:

1. Magic architecture
2. How to write a good test case: 5 tips to write better test cases
3. The 7 characteristics of simple code (KISS)
4. The next software development revolution is here… Are you ready?
5. For god’s sake! Keep it simple!