Exercises — SOLID — Single Responsibility Principle

• computeTotal() → Accounting / Finance (they own tax and pricing rules).
• renderHtml() → Web/UI team (they own how it looks).
• persistToDatabase() → DBA / persistence team (they own storage format).

Three distinct actors ⇒ 3 reasons to change. This class violates SRP: a pricing tweak, a layout tweak, and a schema tweak all land in the same file.

False. SRP counts reasons to change (actors), not number of methods. If all 8 methods change only when one actor (say Accounting) changes its rules, the class has one reason to change and is SRP-clean.

Separate data from policies, one class per actor (see the parent's recipe):

class InvoiceData {          // passive: changes only if the data model changes
    List<LineItem> items; double taxRate;
}
class InvoiceCalculator { double computeTotal(InvoiceData d){...} }  // Accounting
class InvoiceRenderer   { String renderHtml(InvoiceData d){...} }    // Web/UI
class InvoiceRepository { void persist(InvoiceData d){...} }         // DBA

• Shared data lives in InvoiceData (passive, no policy).
• Each policy class serves exactly one actor ⇒ each has $A=1$.
• See Cohesion and Coupling: we raised cohesion (one reason per class) and cut coupling between the three actors.

Add a Facade:

class InvoiceService {              // convenience entry point
    InvoiceCalculator calc; InvoiceRenderer render; InvoiceRepository repo;
    void printAndSave(InvoiceData d){ ... delegates ... }
}

It does not re-violate SRP: the Facade's only reason to change is "the way we wire these three together" (orchestration). It holds no pricing, layout, or storage logic — it merely delegates.

• $A-1=3$ other actors that could be broken.
• Survival per other actor $=1-p=0.85$.
• All three survive (independent) $=0.85^3=0.614125$.
• At least one broken $=1-0.614125=0.385875$.

$R(4)=1-(0.85{)}^3\approx 0.386$ Meaning: ~38.6% of change requests risk breaking an unrelated actor. Splitting into four classes ($A=1$ each) drives $R$ to $0$.

• Design G: $R=1-(0.85{)}^3\approx 0.386$ (from 3.1).
• Design S: $A=1\Rightarrow R=1-(0.85{)}^0=1-1=0$.
• Reduction $=0.386-0=0.386=38.6$ percentage points.

The red curve in the figure climbs steeply with $A$; splitting slides you back to the flat $A=1$ point where the curve touches zero.

It depends on who owns the format. Currency formatting is presentation, owned by the Web/UI actor — so it belongs with the renderer's concern, not the calculator's. Letting the calculator depend on it re-couples Accounting to UI.

• If both truly share it, put formatMoney() in a neutral utility owned by neither business actor (a formatting/i18n actor), so a currency-display change has one owner.
• Blind DRY that merges code across actors recreates the exact cross-actor coupling SRP forbids (see the parent's regularHours() example).

class OrderData { List<Item> items; Customer customer; }   // passive schema
 
class DiscountPolicy   { Money applyDiscounts(OrderData o){...} }  // Sales
class StockReserver    { void  reserve(OrderData o){...} }         // Warehouse
class TaxAndReceipt    { Receipt finalize(OrderData o){...} }      // Finance
class OrderNotifier    { void  notifyCustomer(OrderData o){...} }  // Notifications
 
class CheckoutService {   // Facade: only reason to change = orchestration order
    DiscountPolicy d; StockReserver s; TaxAndReceipt t; OrderNotifier n;
    Receipt checkout(OrderData o){ /* delegate in sequence */ }
}

Justifications (one reason each):

• DiscountPolicy changes ⇔ Sales changes promo rules. Nobody else pulls it.
• StockReserver changes ⇔ Warehouse changes reservation logic.
• TaxAndReceipt changes ⇔ Finance changes tax law / receipt format.
• OrderNotifier changes ⇔ Notifications changes email/SMS wording.
• OrderData changes ⇔ the schema changes (one, data-only reason).
• CheckoutService changes ⇔ the sequence of steps changes — pure wiring.

Each policy class has $A=1\Rightarrow R=0$. This design also opens the door to extending behaviour (new discount type) without editing others.

Make DiscountPolicy an interface (an abstraction) and inject the chosen one:

interface DiscountPolicy { Money applyDiscounts(OrderData o); }
class SeasonalDiscount implements DiscountPolicy {...}
class LoyaltyDiscount  implements DiscountPolicy {...}
class BulkDiscount     implements DiscountPolicy {...}

CheckoutService depends on the interface, not a concrete class, so new strategies plug in with zero edits to CheckoutService, StockReserver, etc.

• This is open for extension, closed for modification.
• Depending on the abstraction (interface) rather than the concretions is Dependency Inversion. SRP gave clean seams; these two principles exploit those seams.

• At time $t_0$: logging serves both teams identically → looks like $A=1$.
• At time $t_1$: security wants audit trails, ops wants debug volume → the same code now has two divergent reasons to change → $A=2$, and $R=1-(1-p{)}^1=p>0$.
• Proof of time-dependence: the count of actors changed while the code did not; therefore $A$ is a property of requirement sources over time, not of the current text.
• Safe rule: design for anticipated axes of change. When two roles could diverge, keep the seam (separate class / interface) even if they agree today. A cheap seam now beats a painful shotgun-surgery split later.

Using $R(A)=1-(1-p{)}^{A-1}$:

• $A=0$ (no actor uses the class): exponent $-1$, $R=1-(1-p{)}^{-1}$. This is mathematically defined but physically meaningless — a class serving nobody has no change requests at all, so the model's domain is $A\ge 1$. Treat $A=0$ as dead code: delete it. Risk is undefined-because-irrelevant.
• $A=1$: $(1-p{)}^0=1\Rightarrow R=0$. SRP-clean: no other actor exists to break.
• $p=0$, any $A$: $(1{)}^{A-1}=1\Rightarrow R=0$. If changes never leak ($p=0$, perfect isolation), coupling costs nothing — but real shared state rarely gives $p=0$.
• $p=1$, $A>1$: $(0{)}^{A-1}=0\Rightarrow R=1$. Every change breaks another actor for certain — the worst god-class.

Misapplied, not wrong. Splitting by method instead of by actor creates a maze of anaemic classes and shotgun surgery — one logical change ripples across many files because one actor's concern got scattered.

• Diagnostic question: "When actor X requests a change, how many files must I edit?"
  • Ideal SRP: exactly one file (that actor's class).
  • Under-split (god-class): one file, but it also breaks other actors ($R>0$).
  • Over-split: many files for one actor → shotgun surgery.
• The sweet spot is one class per actor — the same actor's methods stay together (high cohesion), different actors stay apart.

If you can answer these in your own words, you've mastered D4. What is a "reason to change"? ::: One actor — a single role/stakeholder that requests changes. Why is a Facade not an SRP violation? ::: Its only reason to change is orchestration/wiring; it owns no business policy. Why can blind DRY re-violate SRP? ::: It merges code that changes for different reasons, re-coupling two actors via one helper. What is $R(A)$ when $A=1$? ::: $0$ — no other actor exists to accidentally break. Over-splitting causes which smell? ::: Shotgun surgery — one change touches many files.