Software can organize the same domain in very different ways. Object-oriented design tends to group state with behaviour behind object interfaces, while data-oriented design tends to begin from the transformations a workload performs and choose representations around those access patterns.

Neither approach is a universal default for every problem.

Encapsulation and local reasoning

Objects can give one component clear ownership of state and expose a small behavioural interface. This can make invariants easier to protect and let callers depend on meaning rather than representation.

The same boundary can become costly when a workload must traverse large numbers of small objects, repeatedly cross abstraction boundaries or follow chains of references.

Indirection and coupling

Indirection can decouple callers from implementations, but each layer also has cognitive and runtime cost. Deep inheritance hierarchies or networks of mutually stateful objects can make behaviour difficult to predict because one operation depends on state distributed across many places.

Composition and explicit dependency direction often preserve useful abstraction with fewer assumptions than inheritance-heavy designs.

Workload-oriented representations

Data-oriented design may flatten relationships, separate frequently processed fields and perform operations in batches. This can improve locality and make transformations explicit, but it can also expose representation details or make domain operations less naturally discoverable.

Design for the constraint that matters

A useful architecture balances several goals:

• correctness and enforceable invariants;
• comprehensibility and changeability;
• coupling between components;
• memory footprint and access locality;
• measured runtime performance.

A critique of one paradigm is therefore most useful as a way to reveal hidden costs, not as evidence that every program should use the opposite paradigm.