objects-and-data
Objects & Data Structures
The single most useful question you can ask about a type is: does this thing hide its data behind behavior, or does it expose data for others to work with? Get that decision wrong and every call site pays for it. This file is about drawing that line cleanly — telling objects what to do instead of interrogating them, keeping data structures and objects apart, refusing to chain through strangers, and nailing the contract before the logic.
For splitting the logic itself into small honest functions, see functions; for what to call any of these types, see meaningful-names. Types in every example follow the strict typing rules in type-safety — type over interface, no any, narrow unions.
Expose behavior, not data (Tell, Don't Ask)
An object's job is to hide its data behind operations. When a caller reaches in, pulls out fields, computes something, and writes the result back, the object has become a dumb bag of state and the rule now lives at the call site — usually copy-pasted across three of them. Don't ask an object for its data and act on its behalf. Tell it to do the work.