A root cause analysis of all failures of our software will find a single culprit with multiple costumes. The enemy is always there. Many times disguised as laziness, sometimes simplification, and very frequently with the optimization outfit. If we analyze many common mistakes, we will always find a single culprit. The bloody coupling. Expanding the axioms In previous articles, we talked about the definition of software design in an axiomatic way. We enunciated the single rule to know . And we showed that we should use. what objects to represent in our model the only principle We are going to add the only mistake we should avoid by all means to this axiomatic list. Classes Coupling Examples Global variables link a global reference from the code. This link cannot be easily broken unless we connect to interfaces instead of the classes themselves and use (the D). Having global variables in a structured language involves being attached to a reference that cannot be replaced, mocked or deferred over time. In object-oriented programming using classification languages, ​​the problem is the same. dependency inversion SOLID This is a step back to more pure functional languages ​​where there’s and explicit prohibition enforced by preventing functions from having side effects. If we take an extreme and minimalist position: Every function/method should only invoke objects references by their attributes and/or their parameters. Those plugs that allow us to ‘configure’ the software using arbitrary global references from anywhere on the code. Settings They are a particular case of global references and prevent the correct unit test of a system. If something must be configurable, this possible configuration must be passed as an object as we proposed in this article. In this way we can replace the configuration on tests and have full control and no side effects. Hidden assumptions As we have described in the note on bijections, partially ignoring this principle implies taking the risk of losing information on the contract and making mistakes under different interpretations. In our previous example we represented with the . In this case, we are coupled to the hidden assumption that represents 10 meters number 10 10 10 meters. Hidden assumptions appear at the worst moments of the development cycle. References to null This is a particular case of the above rule. should never be used because it violates our only non-negotiable principle since it is not bijective with any real-world entity ( only exists in the world of developers). Null Null Null: The billion Dollar Mistake If we decide to use a null as a flag of some particular behavior we are coupling the decision of the function implementer (or set an attribute in ) to the one who invokes it (or accesses the attribute) and this ambiguous semantics brings innumerable problems. null Singletons The is a controversial design pattern. If we look at it under the guidance of our single design rule we will discard its use immediately. An object is represented by a singleton if there is only one instance of its class. Singleton pattern This also violates the principle of being declarative since the uniqueness of a concept, in general, is coupled to implementation problems, so we are offending the only design rule that we imposed ourselves. Besides, singletons are generally referenced through their class name, so we add all the problems mentioned in the first paragraph. Singleton Pattern: The Root of All Evil If/Case/Switch and all their friends clauses have a hidden coupling between the and the place where they are and violate the (The O on the solid acronym). If condition evaluated open/closed principle s (and hence should be avoided unless this conditions are business rules thus related to the bijection. If cases) A business rule can be safely stated by an clause but rules such as shouldn’t, since this is not essential on the business rule but accidental (related to the employee status) therefore should be treated with polymorphism. ‘A bonus should be paid to employees with 3 or more years on a company’ If ‘If the employee’s position is junior then pay them 10.000’ In real world employees, are aware of their position but they are not usually aware of their age on the company. Documentation If you need to add comments to your code there’s a smell you might not be declarative enough. https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd Code documentation is many times not synced with the code itself. Many times developers change the code and don’t have enough courage to change the code documentation bound to the code. This is another subtle coupling case. Some months later we read the code and the documentation and need a lot of time to figure out their meaning. Ripple effect If we are faithful to our unique design rule and have a declarative model, we will expect, consequently, that a small change in the requirements will generate a small change in the model and so on. When this does not occur, the dreaded is produced, turning the software unpredictable and full of potential errors that hinder its maintenance. ripple effect Solutions There are many ways to remove coupling once identified. In this article we will see concrete examples of coupling reduction: How to Decouple a Legacy System Conclusions Coupling is necessary because the objects must know each other to collaborate and be able to solve the problems raised in the simulation. Finding out which binding is good versus which one is bad to avoid the wave effect requires a little experience and a lot of staying true to the rules defined in this article. Part of the objective of this series of articles is to generate spaces for debate and discussion on software design. We look forward to comments and suggestions on this article.

Different

Paid

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Nominated for 2022 - HackerNoon Contributor of the Year - Refactoring

Nominated for 2022 - HackerNoon Contributor of the Year - Quality Assurance

Nominated for 2022 - HackerNoon Contributor of the Year - Github

Nominated for 2022 - HackerNoon Contributor of the Year - Machine Learning

Nominated for 2022 - HackerNoon Contributor of the Year - Clean Code

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Nominated for 2022 - the Greatest Storyteller

Nominated for 2022 - HackerNoon Contributor of the Year - Debugging

Portfolio

Software Engineer

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Coupling: The One and Only Software Designing Problem

Coupling: The One and Only Software Designing Problem

Too Long; Didn't Read

Companies Mentioned

Maximiliano Contieri

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Coupling: The One and Only Software Designing Problem

Too Long; Didn't Read

Companies Mentioned

Maximiliano Contieri

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES