Data Class

Classes with only fields, getters, and setters.

Fowler & Beck

Signs of Use (Symptoms)

  • Class has no behavior, just getX(), setX().
  • Logic that manipulates this data is placed elsewhere.

Why it is bad (Consequences)

  • Anemic Domain Model: Behavior is scattered.
  • OOP wasted: Classes become glorified structs.

Why it happens (Root Cause)

ORMs generate classes like this. Developers don’t add behavior.

When it might be okay (Exceptions)

  • DTOs (Data Transfer Objects) for serialization.
  • Records/Value Objects explicitly designed as data holders.

Explanation

Problem

User has name, email, getters, setters. All validation and logic is in UserService.

The Flaw

User is not a true object. The data and the behavior are separated.

Real world analogy

A filing cabinet that just holds papers vs. an assistant who organizes, files, and retrieves them for you.

Refactoring Solution

  • Move Method: Move logic that operates on the data INTO the Data Class.
  • Encapsulate Collection: If exposing internal lists.

Pros and Cons (of the Antipattern)

Pros (Why people do it) Cons (The price you pay)
  • Simple generation
    		•
  • Anemic model
  • Logic spread thin
    		•

    Comparison

    • Related Antipatterns: Feature Envy (logic envies this class).
    • Related Principles: Information Expert (Data Class should hold its own logic).

    Code example

    Typescript

    Bad (The Antipattern)

    Good (The Fix)