0Pricing
Clean Architecture & Design Patterns in Practice · Lesson

Single Responsibility and Open-Closed Mastery

Deepen your command of the first two SOLID principles, learning to identify responsibility boundaries and extend behavior without modifying existing code.

Single Responsibility and Open-Closed Mastery is a free Clean Architecture & Design Patterns in Practice lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Clean Architecture & Design Patterns in Practice learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Back to the Foundations

You have explored Dependency Inversion and Interface Segregation. This lesson masters the remaining pair:

  • Single Responsibility Principle (SRP)
  • Open-Closed Principle (OCP)

These two drive most everyday refactoring decisions.

SRP Defined Precisely

SRP says a class should have one reason to change. A reason to change maps to a single actor or stakeholder.

If billing rules and report formatting can change independently, they belong in different classes.

Spotting an SRP Violation

This class mixes calculation, persistence, and presentation.

class Employee {
    double calculatePay() { return 0; }
    void save() { /* DB code */ }
    String reportHtml() { return "<html>"; }
}

Refactoring Toward SRP

Split responsibilities so each changes for one reason.

class PayCalculator { double calculate(Employee e) { return 0; } }
class EmployeeRepository { void save(Employee e) {} }
class EmployeeReporter { String html(Employee e) { return "<html>"; } }

The Cohesion Payoff

After the split, each class is more cohesive: everything inside relates to one job.

Changes are localized, tests are focused, and accidental coupling between unrelated concerns disappears.

OCP Defined

The Open-Closed Principle: software entities should be open for extension but closed for modification.

You should be able to add new behavior by writing new code, not editing existing, tested code.

An OCP Violation

Adding a shape forces editing this method every time.

double area(Shape s) {
    if (s.type.equals("circle")) return 3.14 * s.r * s.r;
    else if (s.type.equals("square")) return s.side * s.side;
    return 0;
}

Closing It With Polymorphism

Make each shape compute its own area. New shapes require no edits to existing code.

interface Shape { double area(); }
class Circle implements Shape {
    double r;
    public double area() { return 3.14 * r * r; }
}
class Square implements Shape {
    double side;
    public double area() { return side * side; }
}

OCP Through Strategy and Plugins

Common OCP-enabling techniques:

  • Polymorphism over conditionals.
  • The Strategy pattern to inject varying behavior.
  • Plugin or registry mechanisms for adding handlers.

All let you extend by adding, not editing.

How SRP and OCP Reinforce Each Other

A class with a single responsibility is much easier to keep closed for modification, because there is only one axis of change.

When you cleanly separate responsibilities, extension points emerge naturally.

Pragmatic Limits

Do not over-apply. Premature abstraction for variation that never comes adds needless complexity.

Apply OCP at the points your domain actually varies; let the rest stay simple until change demands it.

Quick Check

Test your grasp of SRP and OCP.

Recap

You mastered the first two SOLID principles.

  • SRP: one reason to change per class.
  • OCP: extend by adding, not editing.
  • They reinforce each other and guide most refactorings, applied where variation truly exists.

Frequently asked questions

Is the “Single Responsibility and Open-Closed Mastery” lesson free?

Yes — the full text of “Single Responsibility and Open-Closed Mastery” is free to read here on the web, and the Clean Architecture & Design Patterns in Practice course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Clean Architecture & Design Patterns in Practice course, upgrade to CoddyKit PRO.

What will I learn in “Single Responsibility and Open-Closed Mastery”?

Deepen your command of the first two SOLID principles, learning to identify responsibility boundaries and extend behavior without modifying existing code. You practise Clean Architecture & Design Patterns in Practice with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Clean Architecture & Design Patterns in Practice?

No prior experience is required. Clean Architecture & Design Patterns in Practice on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Single Responsibility and Open-Closed Mastery” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Clean Architecture & Design Patterns in Practice lesson?

Yes. Every Clean Architecture & Design Patterns in Practice lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Deep Dive into Dependency Inversion
  2. Interface Segregation in Practice
  3. Refactoring with Design Patterns
  4. Single Responsibility and Open-Closed Mastery
← Back to Clean Architecture & Design Patterns in Practice