Data-Oriented Programming in Java (MEAP) (Chris Kiehl)（Z-Library）

【One-Line Pitch】 A practical guide to making Java code express its own meaning: model your domain with records, sealed types, and pattern matching so that illegal states simply cannot be written. Best for working Java developers on enterprise codebases who are tired of null checks, ambiguous `String` fields, and state bugs that tests never seem to catch. 【Book Arc】 - **Opening (~0%–10%)**: Frames the core thesis through a small but telling example — changing `String id` to a typed `UUID id` — and argues that most code under-specifies its data. Introduces the value/identity distinction that underpins everything later. - **Early (~10%–30%)**: Builds the vocabulary of values, data, and semantics. Shows how to compare the *meaning* of your data against the *meaning* of the type representing it, and treats any mismatch as a modeling smell. Covers value classes, fluent immutable APIs, and the trade-offs of introducing new types versus accepting "plain" ints and Strings. - **Early–Middle (~30%–40%)**: Moves into algebraic modeling — Product Types (records) and Sum Types (sealed interfaces) — and why knowing this algebra helps you communicate across languages and sketch problems tersely. Uses a checklist/template domain to work through modeling choices. - **Middle (~40%–50%)**: Extends data-orientation from data to *behavior*. Behaviors become discrete input-to-output transformations; wrapper types and enriched data types decouple methods from their external dependencies (databases, APIs, environment reads). - **Middle–Late (~50%+)**: Explores determinism, pure functions, and the tension between identity objects and plain data. Discusses where to draw the line and warns against zealotry — "basically deterministic" is often good enough. 【Key Takeaways】 - **Representation is the highest-leverage decision** (Opening): Choosing `UUID` over `String` for an ID eliminates an entire class of illegal states and the defensive code and tests they require. The book's central move is taking the "obvious" incremental step toward self-describing code. - **Values vs. identity objects** (Early): Values are immutable, have no identity, and cannot change; identity exists independently of any mechanism. Data-oriented programming models identity *with* values rather than through mutable objects. - **Compare meanings to debug your model** (Early): Hold the meaning of your data next to the meaning of its type. If a `double` represents an angle constrained to 0–360 degrees, 99.9999% of representable values are invalid — that gap is a modeling smell. - **Types are a trade-off, not a religion** (Early): Introducing a new type costs boilerplate (minimal with records) but buys safety, correctness, and understandability. The book explicitly warns against both reflexive "boilerplate" dismissal and over-typing everything into madness. - **Product and Sum Types are the algebra underneath** (Early–Middle): Records model "this AND that"; sealed interfaces model "this OR that." Knowing the algebra gives you a language-independent way to discuss and sketch designs. - **Model behaviors around data, not around void methods** (Middle): Behaviors are discrete state-to-state transformations — inputs produce outputs. Making them self-describing and self-enforcing prevents the "wrong invoice passed to the wrong method" class of bug. - **Good data types decouple methods from dependencies** (Middle): A single enriched record can unify multiple service calls and database reads so consumers never need to know about them. The open question the book raises: who is responsible for constructing it? - **Determinism is a spectrum, not a binary** (Late): Pure functions give you omniscience over outputs, but Java inevitably bridges identity objects and data. The book advises against zealotry — "basically deterministic" is usually just as good. 【Reading Tips】 - **Deep-read the early chapters on values, semantics, and type-meaning comparison.** These are the conceptual foundation; everything later is applied modeling. Skim if you already think in types, but don't skip the meaning-comparison exercise. - **Work the domain examples actively.** The book builds up a checklist/template domain and an invoice/late-fee domain across chapters, revising earlier models as it goes. Treat the revisions as the lesson, not the final code. - **Don't get stuck on the algebra section if it's not your thing.** The book itself says the set-theoretic view is "extracurricular." Take away the Product/Sum vocabulary and move on. - **Watch for the trade-off discussions.** The most valuable passages are where the author admits a refactoring is "expensive" or says "it depends" — those are the judgment calls you'll face at work. - **Note the null-safety thread.** The promise of never writing another null check is delivered through modeling, not through tooling; track how each modeling decision removes a null possibility. 【Coverage Limits】 These excerpts cover roughly the first half of the book (through the behavior-modeling and determinism chapters). Later chapters on side-effect management, pattern matching in depth, and full enterprise application structure are not represented here; the guide's Late/Ending arc is inferred from the blurb and later-chapter fragments only.