Pure Fabrication

“What object should have the responsibility, when you do not want to violate High Cohesion and Low Coupling?” – Craig Larman

A “Pure Fabrication” is an artificial class that does not represent a concept in the problem domain, made up to support high cohesion, low coupling, and reuse.

When to use

When assigning a responsibility to any existing domain class would break High Cohesion or Low Coupling.

Why it matters

Cohesion: Keeps domain classes focus on domain logic, not plumbing.
Reusability: You can reuse the utility logic elsewhere.

Signs of Violation

Domain objects are full of SQL queries (save() methods causing coupling to DB).
Domain objects handling file I/O or network requests.

Explanation

Problem

You want to save a User object. Information Expert says User knows its own data, so it should save itself. But if User has SQL code, it’s coupled to the DB, violating Low Coupling and mixing concerns (violating High Cohesion).

Solution

Fabricate a new class (e.g., UserRepository or UserDAO) that doesn’t exist in the real world (users don’t have repositories inside them) but solves the coding problem.

Real world analogy

In the domain of “Banking”, concepts are “Money”, “Notes”, “Accounts”. A “Money Transfer Service” isn’t a tangible object, it’s a fabricated concept to handle the action of moving money so the Money notes don’t have to walk themselves.

Pros and Cons

Pros	Cons
High Cohesion Low Coupling	Can lead to “Anemic Domain Model” if overused (logic stripped from domain objects)

Comparison

Service Pattern: Most “Services” (EmailService, LogService) are Pure Fabrications.
Repository Pattern: A classic Pure Fabrication to handle persistence.