1 Data Oriented Programming
This opening chapter introduces data-oriented programming in Java as a way of designing software around what data is, rather than starting from what objects do. The core idea is to model domain information openly and precisely as data, while still using objects where they are useful for boundaries, state management, and coordination. Data-oriented programming is presented not as a replacement for object-oriented programming, but as a complementary style that makes programs smaller, clearer, and easier to reason about by putting domain meaning directly into the code.
A major theme is that representation shapes understanding. A vague type such as a string identifier forces developers to rely on memory, documentation, coworkers, or production behavior to know what the value really means. Replacing that vague representation with a more precise one, such as a UUID, moves semantics out of people’s heads and into the type system, eliminating many invalid states before they can exist. This same principle applies at larger scales: hidden combinations of fields, nulls, counters, and timestamps often encode important business meaning implicitly, creating ambiguity and bugs. By turning those implicit states into explicit data types, the code gains semantic integrity and becomes self-describing.
The chapter also shows how focusing on data can guide broader program design. Once domain states and transitions are modeled explicitly, methods can become clearer by taking meaningful data as input and returning meaningful data as output, rather than hiding important behavior inside void methods and internal mutation. This naturally encourages code shaped like understandable pipelines, where objects retrieve, manage, and vend well-modeled data. The chapter closes by emphasizing that these ideas do not depend on the newest Java features: modern Java can make data-oriented programming easier, but the essential practice is careful modeling of domain information, even on older JDKs.
Objects and how they communicate is our focus during object-oriented design
Being explicit about what a task can transition to after failing
Representing each decision as a piece of standalone data
Focusing on just the data makes us question our representation
clarifying what we’re talking about
Analyzing the data drives a deeper exploration of the domain
Summary
- Data Oriented programming focuses on representing data "as data"
- Data Orientation does not replace object orientation. The two work together
- In OOP, the interfaces between objects are primarily where we improve designs.
- In DOP, the representation of data is where we improve designs
- While OOP primarily asks “what does it do?”, DOP asks “what is it?”
- To quote Fred Brooks, “data is the essence of programming”
- The types we pick to represent data have a giant effect on our programs
- The wrong data representation allows illegal states to exists.
- The right data representation makes illegal states impossible to express
- A lot of what makes reading code hard is understanding the original author’s intentions
- DOP gets rid of “If X is set then it means…, but if Y is set then …” code ambiguities
- Use concrete data types to represent the meaning behind variable assignments
- Focusing on data leads to “Aha!” moments that deepen your understanding of a domain
- instanceOf is perfectly fine when used with data. The object rules do not apply
- Combining DOP with OOP makes your objects more descriptive and easier to understand
- Code naturally begins to “orient” around a good data model.
- Objects emerge around data in a way that feels inevitable.
- Good data models extends to how we design methods
- void, zero argument methods are an informational black hole.
- Make methods show what they do by using descriptive inputs and return types
- Each chapter in this book will work through a unique example
- All examples in this book are pulled from the real world. You’ll get to see all my mistakes
- We’ll use features from the latest JDKs throughout the book, but you can still follow along with Java 8
FAQ
What is the central idea of Data-Oriented Programming in Java?
Data-Oriented Programming (DoP) is about modeling data “as data” in Java: representing domain information as ordinary, explicit values rather than hiding it inside private instance state. The goal is to make code communicate what the data means, encode business rules into the type system, and reduce ambiguity.Does Data-Oriented Programming mean giving up objects?
No. DoP does not reject objects or object-oriented programming. Instead, it treats objects as one tool among many. Objects are still useful for enforcing boundaries, encapsulating state, and coordinating behavior, but data becomes the foundation around which the design is organized.What does it mean to model data “as data”?
Modeling data “as data” means making information explicit and self-describing in the code. Rather than burying meaning in object internals, comments, or developer knowledge, DoP encourages representing domain concepts directly with precise types and clear structures.Why is representation so important in Data-Oriented Programming?
Representation determines what states a program can express. A vague representation allows invalid or meaningless states, which then require defensive checks and extra tests. A precise representation communicates intent clearly and can make illegal states impossible to construct.Why is String id considered ambiguous?
String id tells readers only that the value is a string named id. It does not explain what kind of identifier it is. If the domain says the ID must be a UUID, then String is too broad because it can contain values like "Hello World!", dates, IP addresses, or any other non-UUID text.Why is UUID id better than String id when the identifier is a UUID?
UUID id expresses the domain meaning directly in the code. It removes ambiguity and prevents non-UUID values from being assigned. This means the program can only represent valid UUID states, reducing the need for defensive validation code and tests around invalid string values.What problem occurs when domain meaning is hidden inside object state?
When meaning is hidden in combinations of fields, developers must infer what those fields mean by reading surrounding code. For example,scheduledAt == null might mean a task is abandoned, but that meaning is not obvious from the field itself. This lack of explicit modeling can lead to misunderstanding, semantic drift, and bugs.How does the scheduled task example demonstrate Data-Oriented Programming?
The original scheduled task code used fields likescheduledAt and attempts to imply different retry decisions. DoP refactors those implicit states into explicit data types such as RetryImmediately, ReattemptLater, and Abandoned. This makes the domain decisions visible and understandable directly from the code.How can Data-Oriented Programming and Object-Oriented Programming work together?
They can complement each other. DoP can improve the internal representation of an object by making its state semantically precise, while object-oriented design can still expose clean public methods such asisAbandoned(). A well-modeled data representation often helps guide better object interfaces.
Data-Oriented Programming in Java ebook for free
