How to Rewrite your Code to Achieve More Flexible Design

CLEAN CODE & REFACTORING | SOLID SERIES

How to Rewrite your Code to Achieve More Flexible Design

The ultimate guide with an example of how to break class and separate concerns using the Single Responsibility Principle

Single Responsibility Principle or SRP stands for the idea that every class or module should have one and only one responsibility. In other words, each class or module should do one thing and do it well.

What Means Responsibility in Software Engineering?

Robert C. Martin defined responsibility as a reason to change. Don’t mistake it with the four main reasons to change your software I blogged about before.

Four Reason to Change your Software

Michael Feathers defines four main reasons to change your code in the book Working Effectively with Legacy Code. I…medium.com

This reason to change is more related to module or application features. In an ideal world, one feature’s behavior change means one class or module to modify.

SRP in Unix

SRP is a well-known principle in software design, and we’ve known for decades that this works very well.

Unix is based on this principle of doing one thing and does it well. Unix is based on the command line, so each command is a small executable program. It has a way to compose those executables into larger-scale programs.

The success of Unix continues by the success of Linux, so we know that there are examples of this principle leading to systems that are very stable and very long-lived.

I found a repository with historical commits since 1970 if you are more interested.

Why is SRP Hard to Implement?

On my hunt for the answer, I came across a great Quora answer from user Pawan Bhadauria, and I want to quote the piece of it.

Consider following sentence: “Tihs snetnece is hrad to raed”.

I bet, you will be able to read this sentence since you comprehend the word as a whole rather than linking each alphabet and making a sentence out of it. Though it directly doesn’t relate to the principle but gives a glimpse into how our brain processes things. Our minds are excellent at seeing a set of behaviour and grouping those together, even when those constitute different responsibilities.

We tend to group behaviors by our nature. The human brain’s strength is also a developer’s kryptonite when he is trying to apply SRP.

Indicators of Violation SRP

The most significant indicator is the size of the class or function. Count of physical lines of code measures functions size. On the other hand, the number of responsibilities measures the class size.

“The first rule of classes is that they should be small. The second rule of the class is that they should be smaller than that.” — Robert C. Martin

Troubles to name the class correctly is one of the indicators as well. The name should be maximally 25 characters long without using words like “if”, “and”, “or” or “but”.

Sometimes, problems with naming the class end by raising a point of view and using the most common name that comes up to the programmer’s mind like OrderService.

The order is processed from filling the basket to receiving a receipt, and it can’t be defined with such a simple name.

Tutorial

Prerequisites

The reader should have basic knowledge about Object-oriented Programming or OOP. Basic understanding of Unit Testing is also appropriate, but not necessary. I am programming in C# language, but Java or other OOP language developers should not have a problem understanding the concept.

Introduction of Project

The repository consists of two projects. First one is the Class Library named BusinessLogic. It includes two folders; Before and After.

Folder Before contains the class FileStore, which is taking care of storing messages into text files.

Folder After contains module consists of three class with the very same responsibilities, as a Before/FileStore class. The content of the directory is the resulting representation of applying the SRP process.

The second project Tests also holds two folders with the same names. Each folder has one class with the very same Unit Tests. The test class Before/FileStoreUnitTests is almost identical to the test class After/MessageStoreUnitTests, but its tests aim to the different system under test as its names suggest.

Side note: if you like thinking about the craft itself — when to refactor, when to leave code alone — I share short, free lessons like that in The Claude Code Memory Starter, a tiny email series you can join in one click.

Identifying the Responsibilities

Gist bellow shows how Before/FileStore.cs the class looks like.

FileStore.cs

Most of you can identify what’s the FileStore class responsibilities. First, that should come at the top of your head is Storing Messages.

Another more obvious responsibility is Logging. Both command methods, Read and Save invokes the NLog functions to log what is currently happening.

The last is not that clear so I’ll tell you. It is what I call an Orchestration. The way of control how the previous two aspects play with each other is also the responsibility.

That’s it! We identified all three, and let’s repeat them.

Storing Messages
Logging Events
Orchestrating interactions

Break the Class

Breaking the class is practically an applying of another well-known principle called the Separation of Concerns.

I like Quora answer by architecture mentor Victor Kane to the question “What is Separation of Concerns in Software Engineering?”

Let me quote the beginning of the answer;

The philosophy of separation of concerns in IT is aimed at preventing “pathological” dependencies between code “concerned” with different domains while attempting to isolate all code concerned with a single “concern”.

“..isolate all code concerned with a single concern.” Sounds familiar right? Now, let’s break the FileStore.

I began with the extraction of Logging concerns. The new StoreLogger class encapsulates implementation details about logging events into its methods. The initialization of StoreLogger is in FileStore constructor and methods are called from the same places as where NLog functions invocations were before.

Interstate Before and After of FileStore.cs

StoreLogger.cs

Now, we need to separate Storing Messages and Orchestration. Let’s logically in our minds separate two implementation details; Storage and Data. In our particular case, the storage is a file system, and the data are messages.

When we consider the dependencies, it appears that the messages should be dependent on its storage, but storage does not need to know anything about the form of data. We can achieve it by extracting the orchestration around the message and let concerns about storage on FileStore.

I separated the original FileStore class into the two new classes; FileStore and MessageStore.

After/FileStore.cs

MessageStore orchestrates the messages, logging, and storage processes.

MessageStore.cs

This time I stuck with the word “store” in the name because it is more precise. Sometimes I struggle to pick the right name for the orchestration responsible classes. So usually I choose the word “Processor”, and I add a prefix which defines the responsibility-for example, a MessageStoringProcessor. The MessageStore name sounds more precise.

I would love to hear how you are dealing with this problem.

Summary

We looked at FileStore class and identify its three responsibilities. First, we extracted the easiest one, the Logging responsibility. Therefore, we separated remaining concerns, Storring Messages, and Orchestration, into the two new classes; MessageStore and FileStore.

The repository also contains the project with unit tests which you can try to run and see if any dropped behavior or function. The green test will prove that we did just right.

Daniel Rusnok's Newsletter

Every month I will send you an email about with list of my newest articles. It will be ofcourse the friendly links…www.danielrusnok.com