Summary

The article outlines nine forms of coupling in software architecture, emphasizing the importance of understanding and managing these dependencies to minimize their impact on software components.

Abstract

The article titled "9 Forms of Coupling in Software Architecture" provides an overview of various types of component coupling within software systems. It underscores that no software system is free from dependencies, and software architects must address the degree of interdependence between components to maintain system integrity and functionality. The author discusses coupling at different abstraction levels, not just in source code but also in infrastructure, and stresses the need for architects to be aware of these couplings when designing components. The types of coupling discussed include use/delegation, composition, creation, inheritance, messages or events, temporal, data types, data, and hardware. Each type is explained with examples, and the article suggests ways to mitigate tight coupling, such as using getters for public variables or employing messaging middleware for loose coupling. The author also references the ISAQB Software Architecture Certification Curriculum and provides a link to Java examples of some coupling forms. Additionally, the article offers a list of related articles for further reading and invites readers to connect on social media platforms.

Opinions

The author suggests that public variables should be made private and accessed via getters to reduce coupling via use/delegation.
Composition is presented as a form of coupling where one class contains another, with the contained class potentially being an integral part of the container class.
The use of creational design patterns, such as Factory and Abstract Factory, introduces coupling via creation, where classes are dependent on a Factory class for instantiation.
Inheritance is described as a strict form of coupling, with child classes inheriting properties and methods from parent classes, which can lead to rigidity in the system.
Messaging and event-driven architectures are highlighted as methods for achieving loose coupling, with asynchronous communication reducing dependencies between components.
Temporal coupling is identified as a dependency where one component cannot perform its function until another component produces an output, which may not necessarily be in the same language or infrastructure.
Coupling via data types is discussed in the context of custom data types, such as UserEntity in JPA, which can cause widespread effects if changed.
The article points out that coupling via data can occur when different components share a database or other data stores, and changes in one can affect the other.
Hardware coupling is mentioned as a low-level concern where components interact through shared hardware resources, such as memory locations.
The author encourages the reader to explore further Java examples and related articles to deepen their understanding of software architecture principles.
The article concludes with an invitation for readers to engage with the author on Twitter and LinkedIn, indicating a preference for professional networking and knowledge sharing within the software architecture community.

9 Forms of Coupling in Software Architecture

Overview of different component coupling types

There is no software system that is free from dependencies and takes no effect if dependent components change. Software architects always have to deal with degree of dependencies between connected components and try to minimise even eliminate this effect. The software component A depends on the software component B, if A requires B for:

Compiling in run-time
being installed
being tested
running of functioning properly

Coupling is a degree of dependence between arbitrary building components.

On different abstraction levels there are different types of coupling. Coupling happens not only in source code level but also in infrastructure and many more. Software Architects need to know these types in order to make correct decisions when designing these components. We are going to take a look at some coupling types based on ISAQB Software Architecture Certification Curriculum.

Coupling via use/delegation…

This type of coupling is one of the classics. Basically, if Class A calls public variable of Class B, they are coupled via use/delegation. Best way out is to make these public variables private, and call them through getters.

Coupling via composition…

In composition relations, as you may know from Object Oriented Programming , Class A contains Class B. in some cases, Class B can is internal part of Class A and does not exist independently. Therefore these classes are coupled via composition.

Coupling via creation…

These type of coupling appears in creational design patterns such as Factory, Abstract Factory. In those design patterns, creation of f.e. Class A or B is delegated to Factory Class. In this terms, Class A or B is coupled to Factory Class via creation. Check out my other article about Design Patterns for deep dive.

5 Software Design Patterns implemented in Spring

Coupling via inheritance…

A dependency where child class should inherit properties and methods from super classes. The coupling via inheritance is very strict, because child gets all what parent does.

Coupling via messages or events…

Messaging middleware and Event Stores is widely used for loose coupling between components. In Messaging, communication is asynchronous: request from sender is received in message queue, from where receiver gets the requests. The sender may or may not know which specific receiver gets the request and it does not way for a reply right away. In Eventing, the idea is similar to messaging but here there is a chronological order of change in state, that is delivered to listener. Since this kind of communication is also asynchronous, coupling is very loose: therefore very desired.

Temporal Coupling…

In these kind of coupling component A depends on component B temporarily, if A can’t perform its jobs till B delivers some output. In this kind of coupling component A and B don’t need to be in same programming language or infrastructure. For example, in order to purchase some items in e-commerce first you need to select and add them to basket.

Coupling via data types…

Based of business needs, there are custom data types created by programmers for further usage. For example in JPA you might have created UserEntity that corresponds to User table in Database. Accordingly, UserEntity will be central data type in software system, where ever you need to deal with a user data. If there is minor changes in UserEntity, all dependent classes will have an effect. This is coupling via data types.

Coupling via data…

Coupling via data occurs, in cases where Component A persists information on a database, configuration file or environment variable, where Component B also communicates. If changes from one component effects another one, through these coupled data, most likely there is a need to loose these coupling.

Coupling via hardware…

Imagine there is a physical hardware or server where Component A has written something on memory location that Component B would also be affected while reading. This kind coupling is via hardware and often happens in low-level programming.

Have a look at following gist for java examples of some of above explained coupling forms.

If you are interested in more Software Architecture topics take a look at below list.

Relevant Articles:

P.S. You can connect with me on twitter or linkedin.