Guidelines To Reduce Coupling And Increase Cohesion

Guidelines To Reduce Coupling And Increase Cohesion

Orthogonality improves a software system’s quality attributes, and low coupling and high cohesion are cornerstones for achieving orthogonality. Therefore, being aware of the most important guidelines to reduce coupling and increase cohesion is crucial for one’s work as a software developer.

The previous blog post talked about the importance of building loosely coupled classes or modules having high cohesion as a means to achieve orthogonality and hence improve the overall quality attributes of the resulting software system. In the following sections, we’re going to build on that knowledge by introducing guidelines for how to achieve low coupling and high cohesion. As always, you can find the full source code for the given examples in this GitHub repository.

Google Jib And Why You Will Love It

Google Jib And Why You Will Love It

Google Jib is a great tool for building Docker images from Maven and Gradle applications – it integrates easily with both and it’s super simple to set up and use. Therefore, it is the perfect companion on anyone’s journey to assemble an application from containerized microservices.

In the context of microservices, you’ll often find yourself building Docker images or, ideally, operating some tool that does it for you. By far the best build tool I’ve encountered so far is Google Jib – it’s very convenient to use, you don’t need a Docker daemon running locally (although you can pass the build to a local Docker daemon), and its smart arranging of Docker filesystem layers ensures only the layer containing modified source code has to be rebuilt, thus speeding up the overall build-and-push process. In this short blog post, we’ll take a look at how to use Google Jib in a Maven project to build and push a Docker image.

Containers And Container Images

Containers And Container Images

Container images encapsulate a service executable along with the libraries and files it needs, and containers provide a way to run many services isolated from one another. That’s why container images and containers are suited perfectly to serve as the basic building blocks for a microservices-based application.

Microservices are everywhere, and they have come to stay. In this blog post, we’ll examine their fundamental building block: container images and containers.

Let There Be Microservices

Let There Be Microservices

The microservice architecture is our way out of monolithic hell. In this blog post, we’ll examine its advantages and disadvantages.

Previously, we’ve looked at a thing called monolithic hell that developers of large applications built using the monolithic architecture style often end up in, and we’ve seen the problems of that architecture style. In this second blog post, then, we’ll take a look at how the microservice architecture addresses those problems.

Monolithic Hell And Why You Don't Want To Be There

Monolithic Hell And Why You Don't Want To Be There

The monolithic architecture style is not inherently evil – its disadvantages only show when the code base grows too much. But because code bases have a habit of doing precisely that, developers often find themselves in monolithic hell, and once there, it’s very difficult to get out.

To gain a better understanding for how a microservice architecture can help us deliver better software faster, the following sections will introduce the older, but still very common monolithic architecture and its problems.

Orthogonality In Software Design

Orthogonality In Software Design

Achieving orthogonality in the design of software is an investment into the future of the resulting software system because orthogonality increases its long-term fitness in terms of quality attributes such as flexibility, testability, and extensibility.

In this blog post, we’ll have a look at the concept of orthogonality in context of software engineering and how it can help us improve the quality attributes of the software we write. We’ll then explore two of the concepts that contribute to building orthogonal software systems.

The Link Between Software And Broken Windows

The Link Between Software And Broken Windows

The most significant accelerator of software degradation is the team’s working culture. Even minor flaws in a project’s code base can cause the working culture to deteriorate and hence drive software degradation.

This blog post is about the link between software and broken windows (no, not the operating system – literally a window, you know, the sort of window you can look out of) and what this link means for us as software developers.

Pagination