Single Responsibility

This is the first principle of writing software that does not collapse under its own weight. When you can see that a module has one job and one reason to change, you can split a tangled program into pieces you can name, test, and fix in isolation. That skill is the foundation for everything in your library: high cohesion and loose coupling, separation of concerns, layered architecture, hexagonal architecture, ports and adapters, and eventually the ability to sketch an entire system so that changing one part does not explode the rest. Without it, every later architectural pattern is just decoration on a messy pile.

Think of any tool you use every day. A kitchen knife cuts; it does not also stir, measure, or boil water. You reach for it because you know exactly what it does and what it does not do. A screwdriver drives screws; it does not hammer nails. Now imagine a single tool that is a knife, a spoon, a ruler, and a hammer all fused together. It might do all four jobs, but each one is awkward, and when one part breaks, you lose the whole tool. Software modules are the same. A module is a unit of code — a file, a class, a function — that has a name and a purpose. A well-designed module has one purpose, narrow enough that you can say it in one short sentence, like 'This module formats dates' or 'This module checks whether a user is allowed to view this page.' If you find yourself saying 'This module handles billing and sends emails and logs errors,' you have fused a knife with a hammer. The single responsibility principle is the rule that pushes you to keep those jobs separate. It is not about making code shorter or cleverer; it is about making change safe. When a requirement changes — and it always does — a module with one job changes for one reason only. If a module has three jobs, a change to one job risks breaking the other two. You want each change to touch as few places as possible, and each place to have one clear reason to exist.

Consider a small restaurant kitchen. There is a chef who cooks, a dishwasher who cleans plates, and a waiter who takes orders. Each person has one clear responsibility. Now imagine that the waiter also washes dishes when things are slow, the chef also greets customers at the door, and the dishwasher also handles the cash register. The restaurant becomes chaotic: a customer asks the chef about a reservation, and the chef burns the food; a dish breaks, and the dishwasher is handling cash, so nobody notices. When a problem happens, it is hard to tell who is responsible. The same chaos happens in code. A module that validates user input and also writes to a database and also formats an error message is a person doing three jobs. When a bug appears, you have to check three different concerns to find it. When you need to change the database library, you might accidentally break the input validation. The single responsibility principle says: one person, one job. The chef cooks. The waiter serves. The dishwasher cleans. In code, one module validates input. Another module writes to the database. Another formats error messages. Each can be changed, tested, and understood on its own. The analogy breaks down a little: in a restaurant, one person can do multiple jobs if they are skilled and the restaurant is small. That is true in code too — a tiny script can do several things and still be fine. The principle is about managing complexity. When the restaurant grows, the waitress who also cooks will become a bottleneck. When the codebase grows, a module that does two things will become a source of bugs. The further you go, the more the single responsibility principle pays off.

A module should have one reason to change, meaning its purpose is narrow enough to state in a single sentence without using the word 'and' to connect different jobs.

You have not studied any other topics yet, so everything here is fresh ground. This principle is the seed. It connects directly to the 'Cohesion and Coupling' notes in your library — a module with one responsibility has high cohesion, because its contents are all about the same thing. It is the first step toward 'Separation of Concerns' and 'Layered Architecture', where different concerns live in different layers. When you later learn about 'Dependency Inversion' and 'Ports and Adapters', you will see that you cannot define a clean interface for a module that does five unrelated things. For now, hold onto this: every module you write should answer the question 'What do you do?' in one sentence.