Single responsibility S

01 / MEET THE PRINCIPLE

What is Single responsibility?

Keep together the things that change for the same reason; separate things that change for different reasons.

First understand the idea. Then explore why it helps, before bringing it to life with a programmable toy robot.

WHERE THE IDEA BEGAN

A little history.

Robert C. Martin named and popularised SRP. In his 2014 explanation, he connects a reason to change with the people or business roles requesting that change, drawing on earlier ideas about cohesion and separating concerns.

02 / WHY IT MATTERS

Why use it?

Where it helps

Useful in order processing, reports and booking systems. For example, pricing rules, PDF formatting and saving a booking often answer to different business needs.

Why use it?

Changes become easier to locate and review. Tests for a light sequence can focus on colours and timing without setting up motors or audio.

What if you ignore it?

Unrelated changes accumulate in one place. A harmless formatting update can require retesting business rules and creates more opportunities for conflicting edits. A fault is possible, not inevitable.

KNOW THE TRADE-OFF

Useful, not absolute.

A responsibility is not the same as one method. A cohesive class can contain several methods. Splitting every tiny action into a separate class can make the story harder to follow.

Next, step into the story and see this problem through a familiar situation.

03 / ONCE UPON A CHANGE

New lights.
Same little robot.

You’ve built a little robot that rolls across your desk, flashes its eyes and plays a victory tune. Now you want rainbow eyes. Easy, right? Except its movement, lights and sound all live in one giant RobotController. You open the file to change a colour and find yourself scrolling past wheel speeds and sound effects.

Then a friend wants to add a moonwalk while you’re editing the light show. You’re both changing the same class for completely different reasons. Nothing has to break—but you’ve made a small upgrade harder to work on and check.

Give movement, lights and sound their own modules. The robot still performs one coordinated routine; each module owns the rules for its part. New rainbow eyes? Change the light controller. Leave the wheel maths alone.

Turn to “Try it” to change the design and see what happens.

04 / PULL THE PAPER TAB

What happens
when things change?

One RobotController owns movement, lights and sound.

One RobotController owns movement, lights and sound.

Choose a scenario, then try the change.

An illustrative model, not a benchmark or a claim that every design change causes a bug.

05 / FROM STORY TO CODE

Spot the dependency.

Keep together the things that change for the same reason; separate things that change for different reasons.

Before

class RobotController
{
    void Move(Command command) { /* wheel rules */ }
    void LightUp(Theme theme) { /* LED patterns */ }
    void Play(Cue cue) { /* sound selection */ }
}

A MORE FOCUSED DESIGN

After

class MovementController { /* wheel rules */ }
class LightController { /* LED patterns */ }
class SoundPlayer { /* sound selection */ }

// A routine coordinates the three modules.
// It does not own their internal rules.

Illustrative C# sketches. Supporting types and method bodies are omitted; these snippets are not executed in the page.

06 / MAKE IT STICK

Take the idea
with you.

Keep together the things that change for the same reason; separate things that change for different reasons.

Try the question opposite, then continue to the next principle.