Common Misconceptions - Learning Module

Loading content...

0/246

SRP Doesn't Mean Tiny Classes Everywhere

The Fragmentation Fallacy

If the 'one method per class' misconception is SRP's most obvious misinterpretation, the 'tiny classes everywhere' fallacy is its most insidious cousin. This belief manifests as a relentless drive to break every class into smaller pieces—regardless of whether such decomposition serves any design goal.

Developers infected with this thinking treat class size as a metric in itself. They view any class over 100 lines with suspicion, any class over 200 with alarm, and any class over 500 as an unforgivable sin. The result is codebases where meaningful abstractions are shattered into dozens of collaborating micro-classes, each doing too little to be comprehensible in isolation.

This isn't principled design—it's Tetris anxiety applied to software architecture.

The Hidden Cost

Class explosion doesn't just make code harder to navigate—it shifts complexity from 'within classes' to 'between classes.' You trade local complexity (large, rich classes) for distributed complexity (intricate webs of tiny collaborators). The second is far harder to debug, test, and evolve.

What You Will Learn

By the end of this page, you will understand why class size is not a valid proxy for SRP compliance. You'll learn to recognize the symptoms of over-decomposition and discover strategies for finding the right level of class granularity.

Size vs. Responsibility: Why They're Orthogonal

The fundamental error in 'tiny classes everywhere' thinking is conflating size (lines of code, method count) with responsibility (reason to change). These concepts are orthogonal—a class can be large with one responsibility or small with multiple responsibilities.

A thought experiment:

Consider two classes:

Class A: 50 lines, handles both user authentication and audit logging
Class B: 500 lines, implements a comprehensive sorting algorithm with multiple strategies

Which violates SRP? Class A—despite being 10x smaller. Its two responsibilities (authentication vs. logging) serve different stakeholders and change for different reasons.

Class B, though large, might have perfect SRP compliance if all 500 lines serve the single purpose of 'sorting data efficiently' and would only change when sorting requirements change.

Size vs. Responsibility Matrix
Class Type	Size	Responsibility Count	SRP Compliance
Focused Domain Entity (e.g., Invoice)	Large (300+ lines)	One (invoice management)	✅ Compliant
God Class (e.g., UserManager)	Large (500+ lines)	Many (auth, profile, billing)	❌ Violation
Micro-class (e.g., EmailValidator)	Small (20 lines)	One (validation)	✅ Compliant
Hidden Multi-tasker	Small (50 lines)	Two (format + persist)	❌ Violation

The correct measure:

SRP compliance is measured by:

Cohesion: Do all class members work toward a unified purpose?
Stakeholder count: How many actors would request changes?
Change coupling: When one method changes, do others need to change too?

None of these correlate directly with line count. A 500-line class with perfect cohesion is superior to five 100-line classes with tangled dependencies.

The Size Trap

When code review feedback says 'this class is too big,' the appropriate response isn't automatic splitting—it's analysis. Ask: 'Is it big because it has multiple responsibilities, or because one responsibility is genuinely complex?' Only the former warrants decomposition.

The Real Costs of Over-Decomposition

Teams that aggressively fragment their classes pay hidden costs that accumulate over time. Understanding these costs helps resist the siren call of endless decomposition.

The Hidden Tax of Tiny Classes

•Cognitive Overhead — Understanding a feature requires assembling a mental model from 15 classes instead of 3. Developers spend more time navigating than coding.
•Indirection Explosion — Execution flow bounces between classes, making debugging a treasure hunt. Stack traces become novels.
•Wiring Complexity — Tiny classes need to collaborate, requiring injection, factories, or explicit wiring. Dependency management becomes a full-time concern.
•Naming Exhaustion — When everything is a class, you run out of meaningful names. OrderProcessor, OrderHandler, OrderManager, OrderService—what's the difference?
•Testing Fragmentation — You test each micro-class in isolation, but real bugs occur in their interactions. Mock-heavy tests pass while integration fails.
•Semantic Blur — Domain concepts lose meaning when split across many classes. An 'Order' becomes a constellation of OrderValidator, OrderPersister, OrderNotifier, losing its identity.

The coupling transfer:

When you split a large class into many small ones, you don't eliminate complexity—you transfer it. Internal complexity (within a class) becomes external complexity (between classes).

Consider what happens when you fragment a ReportGenerator into DataFetcher, DataTransformer, ReportFormatter, ReportRenderer, and ReportExporter:

Each class is simpler in isolation
But they must collaborate in specific sequences
Changing the report format might touch Transformer, Formatter, and Renderer
The 'Report' concept is now spread across 5 files

You've traded one 300-line class you could understand for five 60-line classes that only make sense together.

CouplingTransfer.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// ❌ Over-decomposed: 5 classes, high inter-class coupling
public class ReportOrchestrator {
    private final DataFetcher dataFetcher;
    private final DataTransformer transformer;
    private final ReportFormatter formatter;
    private final ReportRenderer renderer;
    private final ReportExporter exporter;
    
    public void generateReport(ReportRequest request) {
        RawData data = dataFetcher.fetch(request.getDataSource());
        TransformedData transformed = transformer.transform(data, request.getRules());
        FormattedReport formatted = formatter.format(transformed, request.getTemplate());
        RenderedReport rendered = renderer.render(formatted);
        exporter.export(rendered, request.getDestination());
    }
}
 
// Each class knows about adjacent classes. 
// Change one, potentially change all.
// The "report" concept lives nowhere and everywhere.
 
// ✅ Cohesive: One class with clear internal organization
public class ReportGenerator {
    private final DataSource dataSource;
    private final TemplateEngine templateEngine;
    
    public Report generate(ReportRequest request) {
        RawData data = fetchData(request.getDataSource());
        ReportData reportData = transformData(data, request.getRules());
        return buildReport(reportData, request.getTemplate());
    }
    
    public void export(Report report, Destination destination) {
        String rendered = render(report);
        write(rendered, destination);
    }
    
    // Private methods organize internal complexity
    private RawData fetchData(DataSourceSpec spec) { ... }
    private ReportData transformData(RawData data, Rules rules) { ... }
    private Report buildReport(ReportData data, Template template) { ... }
    private String render(Report report) { ... }
    private void write(String content, Destination destination) { ... }
}
 
// "Report generation" lives in one place.
// Internal methods can change freely without affecting other classes.
// The concept is coherent and navigable.

Complexity Conservation Law

Complexity doesn't vanish when you split classes—it transforms. Internal complexity (private methods, internal state) becomes external complexity (dependencies, interfaces, coordination). Choose which form of complexity is more manageable for your specific situation.

When Small Classes Make Sense

Criticizing 'tiny classes everywhere' doesn't mean endorsing monolithic god classes. Small classes absolutely have their place—but that place is defined by design principles, not line count goals.

Legitimate reasons for small, focused classes:

When Decomposition Is Warranted

•Different actors — When parts of a class serve different stakeholders who change requirements independently, separation prevents accidental coupling.
•Testability isolation — When a component has complex dependencies that make testing difficult, extracting it behind an interface enables mocking.
•Reusability — When functionality will be used in multiple contexts, extracting it prevents duplication.
•Rate of change — When some code changes frequently while other code is stable, separation prevents unnecessary churn.
•Deployment boundaries — When parts of code need to be deployed independently (microservices, plugins), class boundaries matter.
•Strategy variation — When algorithms vary at runtime (Strategy, State patterns), separate classes represent alternatives cleanly.

The key distinction:

Good decomposition is pull-based — forces in your system pull code apart. Bad decomposition is push-based — artificial rules push code apart.

Pull-Based (Good)	Push-Based (Bad)
'Marketing and Finance need different reports'	'Classes should be under 100 lines'
'We need to mock the database in tests'	'Each method deserves its own class'
'Sorting algorithms vary by data type'	'Let's split this because it feels big'
'Notification logic is shared by 3 services'	'Uncle Bob says single responsibility'

Pull-based decomposition responds to real design pressures. Push-based decomposition responds to arbitrary metrics.

The Design Pressure Test

Before splitting a class, identify the design pressure forcing the split. If you can't name a concrete scenario (different stakeholders, testing difficulty, reuse need, deployment boundary), the split is probably premature and will add complexity without benefit.

Finding the Right Level of Granularity

The optimal class size isn't a fixed number—it's a context-dependent balance between competing concerns. Several factors influence where your classes should land on the size spectrum.

Factors favoring larger classes:

When Larger is Better

•Strong cohesion — All methods use common state and serve one purpose
•Single stakeholder — One team or actor owns all functionality
•Co-changing code — Methods always change together
•Domain concept — Class represents a real-world entity (Invoice, Order, User)
•Algorithmic complexity — Complex logic needs room to express itself
•Stable abstractions — Interface is stable even as implementation evolves

When Smaller is Better

•Low cohesion — Methods cluster into unrelated groups
•Multiple stakeholders — Different teams need different parts
•Independent changes — Parts evolve at different rates
•Cross-cutting concern — Functionality used across boundaries (logging, validation)
•Plugin architecture — Extensions need clear extension points
•Testability needs — Parts need independent isolation

The 'reason to read' heuristic:

A practical test: Can a developer understand this class by reading it top-to-bottom in one sitting, building a coherent mental model?

If yes, the class might be at appropriate size (even if large)
If no, because the class does unrelated things, splitting is warranted
If no, because it's just too much detail, consider if that complexity is essential

A 500-line PaymentProcessor that clearly progresses through validation, authorization, settlement, and reconciliation can be readable. A 200-line class that jumps between user preferences and API throttling cannot.

Granularity.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// A well-sized class has a clear narrative
 
public class OrderFulfillment {
    
    // The class tells a story. Each section flows to the next.
    
    // === Section 1: Order Intake ===
    public FulfillmentResult fulfill(Order order) {
        validate(order);
        Order reserved = reserveInventory(order);
        PaymentConfirmation payment = processPayment(reserved);
        ShipmentPlan shipment = planShipment(reserved, payment);
        return createResult(reserved, payment, shipment);
    }
    
    // === Section 2: Validation ===
    private void validate(Order order) {
        validateItems(order);
        validateShippingAddress(order);
        validatePaymentMethod(order);
    }
    
    private void validateItems(Order order) { ... }
    private void validateShippingAddress(Order order) { ... }
    private void validatePaymentMethod(Order order) { ... }
    
    // === Section 3: Inventory ===
    private Order reserveInventory(Order order) {
        for (LineItem item : order.getItems()) {
            reserveItem(item);
        }
        return order.withReservations(getReservations());
    }
    
    private void reserveItem(LineItem item) { ... }
    private List<Reservation> getReservations() { ... }
    
    // === Section 4: Payment ===
    private PaymentConfirmation processPayment(Order order) { ... }
    
    // === Section 5: Shipment ===
    private ShipmentPlan planShipment(Order order, PaymentConfirmation payment) { ... }
    
    // === Section 6: Result Building ===
    private FulfillmentResult createResult(
        Order order, 
        PaymentConfirmation payment, 
        ShipmentPlan shipment
    ) { ... }
}
 
// This might be 300+ lines, but the *narrative is coherent*.
// A developer can read it and understand order fulfillment.
// Splitting into FulfillmentValidator, InventoryReserver, PaymentProcessor, 
// ShipmentPlanner would scatter the story across 5 files.

The Refactoring Resistance Principle

Here's a powerful heuristic: Refactoring toward smaller classes should meet resistance. If splitting a class is easy and obvious, you're probably identifying a genuine responsibility boundary. If it's awkward and forces artificial decisions, the class might be correctly unified.

Resistance signals:

Signs a Split Is Forced

•Passing everything as parameters — The new class needs access to most of the original class's state
•Circular dependencies — The extracted class needs to call back into the original class
•Artificial interface — You can't write a clean interface without exposing implementation details
•Naming struggles — You can't name the new class without using the original class's name plus a suffix
•Test duplication — Testing the new class requires duplicating setup from the original's tests
•Contextual methods — The extracted methods only make sense in the context of the original class

The extraction test:

When considering a split, attempt the extraction mentally (or on a branch). Ask:

Can the new class exist independently? Does it have a clear purpose without reference to the original?
Is the interface minimal? Does the original class need only a few method calls to collaborate with the new class?
Is the name natural? Does a domain-relevant name emerge, or do you resort to XxxHelper, XxxUtils, XxxProcessor?
Are tests simpler? Can each class be tested with less setup than the original needed?

If you answer 'yes' to all four, the split is probably sound. If you struggle, the original class may embody a genuinely unified concept.

Trust the Resistance

When extraction feels forced—requiring bidirectional dependencies, passing extensive context, or creating leaky abstractions—trust that feeling. The resistance is the code telling you the current structure might actually be appropriate. Not all large classes are god classes.

Case Study: The E-commerce Order Entity

Let's examine a realistic case: an Order entity in an e-commerce system. We'll compare the 'tiny classes' approach with a cohesive approach and see the tradeoffs.

The over-decomposed version:

OverDecomposedOrder.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// ❌ Over-decomposed: 8 classes for one domain concept
 
public class Order {
    private OrderId id;
    private List<LineItem> items;
    // Just data, no behavior - an anemic model
}
 
public class OrderValidator {
    public ValidationResult validate(Order order) { ... }
}
 
public class OrderPricingCalculator {
    public Money calculateTotal(Order order) { ... }
}
 
public class OrderTaxCalculator {
    public Money calculateTax(Order order) { ... }
}
 
public class OrderDiscountApplier {
    public Order applyDiscounts(Order order, List<Coupon> coupons) { ... }
}
 
public class OrderStatusManager {
    public void transition(Order order, OrderStatus newStatus) { ... }
}
 
public class OrderShippingCalculator {
    public ShippingOptions calculateShipping(Order order) { ... }
}
 
public class OrderInventoryChecker {
    public AvailabilityResult checkAvailability(Order order) { ... }
}
 
// Problems:
// 1. "Order" as a concept is scattered across 8 files
// 2. Order class is anemic - just a data bag
// 3. Business rules live in services, not the entity
// 4. To understand orders, you must trace 8 classes
// 5. Changing order logic requires coordinating multiple files

The cohesive version:

CohesiveOrder.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
// ✅ Cohesive: One rich domain entity (might be 400+ lines)
 
public class Order {
    private final OrderId id;
    private final CustomerId customerId;
    private final List<LineItem> items;
    private final ShippingAddress shippingAddress;
    private OrderStatus status;
    private List<AppliedDiscount> discounts;
    private Money taxAmount;
    private LocalDateTime createdAt;
    private LocalDateTime lastModifiedAt;
    
    // === Factory Method ===
    public static Order create(CustomerId customerId, ShippingAddress address) {
        Order order = new Order(OrderId.generate(), customerId, address);
        order.validate();
        return order;
    }
    
    // === Line Item Management ===
    public void addItem(Product product, int quantity) {
        validateEditable();
        LineItem item = LineItem.create(product, quantity);
        items.add(item);
        recalculateTotals();
        touch();
    }
    
    public void removeItem(LineItemId itemId) {
        validateEditable();
        items.removeIf(item -> item.getId().equals(itemId));
        recalculateTotals();
        touch();
    }
    
    public void updateQuantity(LineItemId itemId, int newQuantity) {
        validateEditable();
        findItem(itemId).updateQuantity(newQuantity);
        recalculateTotals();
        touch();
    }
    
    // === Discount Handling ===
    public void applyDiscount(Discount discount) {
        validateEditable();
        if (!discount.isApplicableTo(this)) {
            throw new InvalidDiscountException(discount);
        }
        discounts.add(discount.applyTo(this));
        recalculateTotals();
        touch();
    }
    
    // === Pricing ===
    public Money getSubtotal() {
        return items.stream()
            .map(LineItem::getLineTotal)
            .reduce(Money.ZERO, Money::add);
    }
    
    public Money getDiscountAmount() {
        return discounts.stream()
            .map(AppliedDiscount::getAmount)
            .reduce(Money.ZERO, Money::add);
    }
    
    public Money getTaxAmount() {
        return taxAmount;
    }
    
    public Money getTotal() {
        return getSubtotal()
            .subtract(getDiscountAmount())
            .add(getTaxAmount());
    }
    
    // === Lifecycle ===
    public void submit() {
        validateForSubmission();
        this.status = OrderStatus.SUBMITTED;
        touch();
    }
    
    public void confirm() {
        validateTransition(OrderStatus.CONFIRMED);
        this.status = OrderStatus.CONFIRMED;
        touch();
    }
    
    public void ship(TrackingInfo trackingInfo) {
        validateTransition(OrderStatus.SHIPPED);
        this.status = OrderStatus.SHIPPED;
        // ... handle tracking
        touch();
    }
    
    public void cancel(CancellationReason reason) {
        validateCancellable();
        this.status = OrderStatus.CANCELLED;
        touch();
    }
    
    // === Queries ===
    public boolean isEditable() {
        return status == OrderStatus.DRAFT;
    }
    
    public boolean isCancellable() {
        return status.isBefore(OrderStatus.SHIPPED);
    }
    
    public int getItemCount() {
        return items.stream().mapToInt(LineItem::getQuantity).sum();
    }
    
    // === Private Helpers ===
    private void validateEditable() {
        if (!isEditable()) {
            throw new OrderNotEditableException(id, status);
        }
    }
    
    private void validateForSubmission() {
        if (items.isEmpty()) {
            throw new EmptyOrderException(id);
        }
        // ... additional validation
    }
    
    private void validateTransition(OrderStatus target) {
        if (!status.canTransitionTo(target)) {
            throw new InvalidTransitionException(id, status, target);
        }
    }
    
    private void recalculateTotals() {
        this.taxAmount = TaxCalculator.calculate(this);
    }
    
    private void touch() {
        this.lastModifiedAt = LocalDateTime.now();
    }
    
    private LineItem findItem(LineItemId itemId) {
        return items.stream()
            .filter(item -> item.getId().equals(itemId))
            .findFirst()
            .orElseThrow(() -> new LineItemNotFoundException(itemId));
    }
}

Comparing the approaches:

Aspect	Over-Decomposed	Cohesive
Files to understand 'Order'	8	1
Where business rules live	Scattered services	The entity itself
Encapsulation	Poor (exposed state)	Strong (controlled transitions)
Testability	Mock-heavy	Straightforward
Discoverability	Hunt through packages	Navigate one file
Domain alignment	Anemic model	Rich domain model

The cohesive Order might be 400 lines, but it represents one domain concept completely. An engineer reading it understands orders. The over-decomposed version requires assembling knowledge from 8 files.

Domain-Driven Guideline

In Domain-Driven Design, entities should encapsulate their behavior, not just their data. A rich Order entity that manages its own lifecycle, pricing, and validation honors both SRP and DDD principles. One responsibility: being a complete, valid Order.

Summary: Size Isn't Responsibility

We've examined why 'tiny classes everywhere' is a misapplication of SRP. Here are the key insights:

Key Takeaways

•Size and responsibility are orthogonal — A large class can have one responsibility; a small class can have several
•Class explosion trades complexity forms — You exchange internal complexity for external (coordination) complexity
•Decomposition should be pull-based — Real design pressures (different stakeholders, testability, reuse) justify splits, not arbitrary size limits
•Natural resistance signals unity — If splitting feels forced—requiring extensive parameters, circular dependencies, or artificial interfaces—the class might be correctly unified
•Rich domain models are often large — Domain entities that encapsulate behavior will accumulate methods—this is good design, not bloat
•The goal is coherent concepts — Can you understand a class by reading it? Does it represent one thing completely? Size serves this goal, not the reverse

What's next:

We've now debunked the two most common SRP misconceptions: 'one method per class' and 'tiny classes everywhere.' Next, we'll explore how to balance SRP with pragmatism—recognizing that principles exist to serve working software, not the reverse.

Page Complete

You now understand that class size is not a valid measure of SRP compliance. Focus on cohesion, stakeholder alignment, and change drivers—not line counts. Large cohesive classes often serve design better than scattered micro-classes.