Foundations — SOLID — Single Responsibility Principle

This page builds — from nothing — every word and symbol the parent note SRP topic assumes you already know: class, module, actor, reason to change, coupling, and the small pieces of probability ($p$, $A$, $1-p$, the power $(1-p{)}^{A-1}$). Do not skip: even if a word feels familiar, we anchor it to a picture so the rest of the topic clicks.

0. What is a class / module? (the box that holds code)

Before we can say "a class should have one reason to change," we must agree on what a class is.

• Data (fields): the facts it remembers, e.g. an employee's name, hoursWorked, rate.
• Methods (actions): things it can do, e.g. calculatePay(), save().

Look at the figure: the outer rectangle is the class box. The top drawer holds fields (facts); the bottom drawer holds methods (verbs). Everything SRP talks about is which methods belong in the same box.

1. What is a reason to change? (the heart of everything)

The parent note's entire definition rests on this phrase, so we earn it carefully.

Picture a class box with arrows pointing into it. Each arrow is a person (or role) who might one day say "change this behaviour." If one arrow points in, the box has one reason to change. If two arrows point in, it has two.

• Left box (good): one arrow — one reason to change.
• Right box (bad): two arrows from two different roles — two reasons to change. When Accounting pulls its arrow, the shared code moves and HR's arrow gets yanked too.

2. What is an actor? (a name for each arrow)

The word "actor" is just a tidy label for "the boss behind an arrow." SRP restated with this vocabulary:

We need the word actor because "reason to change" is abstract, but an actor is a concrete person you can point at on an org chart. That is why the topic keeps saying "which stakeholder asks for this change?"

3. Cohesion and coupling (how tangled the boxes are)

The parent links Cohesion and Coupling and says "SRP is high cohesion + low coupling." We must define both from zero.

• Top pair: high coupling — a taut string means touching one jiggles the other.
• Bottom pair: low coupling — slack string, each moves freely.

4. The probability toolkit ($p$, $1-p$, multiplying, powers)

The parent's formula $R(A)=1-(1-p{)}^{A-1}$ uses four ideas from probability. We build each with a picture — no prior stats needed.

4a. What is a probability $p$?

Picture a bar of length $1$. Shade a fraction $p$ of it — that shaded part is "the change breaks another actor."

4b. Why $1-p$? (the complement)

If the shaded part $p$ means "breaks," the unshaded part is "does not break." The whole bar is $1$, so:

We use $1-p$ (called the survival probability) because it is easier to ask "did everything survive?" than "did at least one break?" — the survivals multiply cleanly, as we see next.

4c. Why multiply? (independent events)

Suppose two other actors each independently survive a change with probability $1-p$. "Both survive" is like flipping two coins and asking for two heads. For independent events, you multiply the chances:

The figure shows a probability tree: each fork splits into "survive" ($1-p$) and "break" ($p$). Follow the top-top branch (all survive) — you multiply along the path, giving $(1-p{)}^2$ for two actors.

4d. What is the power $(1-p{)}^{A-1}$?

When one actor makes the request, there are $A-1$ other actors who might get broken. All must survive, so we multiply $(1-p)$ by itself $A-1$ times. Writing "$(1-p)$ multiplied $A-1$ times" as a power is just shorthand:

Now the parent's formula reads itself: $R(A)=\underset{\text{whole bar}}{\underbrace{1}}-\underset{\text{everyone else survives}}{\underbrace{(1-p{)}^{A-1}}}=P(\text{at least one other actor breaks})$

5. Two named dangers the topic mentions

Quick anchors so the words aren't scary later:

Also note DRY Principle (Don't Repeat Yourself): sharing a helper to avoid duplication is good — unless the helper is shared by two actors, which secretly re-couples them. That is the trap in the parent's regularHours() example.

Prerequisite map

Equipment checklist