Skip to main content

Small Classes Organize for Change

What this concept is​

Small classes are measured by responsibilities, not by raw line count. A class should have one main reason to change. Cohesion matters more than squeezing everything into one object.

Why it matters here​

When code grows, the class level becomes where responsibility creep becomes expensive. Huge classes are hard to name, hard to test, and hard to change without collateral damage.

Concrete example​

A UserManager that validates input, stores users, hashes passwords, sends emails, records analytics, and formats API responses is not a coherent class. Even if each method is short, the class has too many reasons to change.

Splitting responsibilities into collaborators often makes each piece easier to name and test:

  • UserValidator
  • UserRepository
  • PasswordHasher
  • RegistrationNotifier

Common confusion / misconception​

Small classes do not mean class explosion for its own sake. Dogmatic splitting can create pointless wrappers. The goal is cohesive responsibility, not maximum object count.

How to use it​

Use these signals:

  • you need and, or, or but to describe the class
  • the class name contains vague bucket words
  • unrelated methods change for unrelated reasons
  • tests for one feature require setting up lots of unrelated state

Check yourself​

Why is the description sentence for a class often a useful SRP test?

Mini drill or application​

Describe one class you own in 25 words or fewer. If you need and, or, or but, list the separate responsibilities that are colliding.

Read this only if stuck​