What is a "hybrid" class in the objects-versus-data-structures sense, and how do Tell-Don't-Ask and feature envy relate to it?

## Hybrid defined Two coherent designs exist: **objects** (hide data, expose behaviour) and **data structures** (expose data, no behaviour). A **hybrid** sits in the middle: it exposes its data *and* contains meaningful behaviour. Symptoms: - A full set of public getters and setters, plus methods enforcing business rules. - Callers writing rules from the accessors: `if (order.getStatus() == NEW && order.getLines().size() > 0 && order.getCustomer().isActive())`. - Documentation or reviews arguing about "should this validation live in the service or the entity?" - and both answers being partly true in the codebase. Why it is the worst of both worlds: - **Invariants leak.** A setter can put the object into a state its own methods swore was impossible. - **Duplication.** The same rule gets re-derived at every caller that reaches into the fields. - **Change is expensive on both axes.** Adding a type is not cheap (callers switch on fields) and adding an operation is not cheap (behaviour is already scattered). - **Serialization/versioning friction.** Behaviour and lifecycle assumptions ride along with data you wanted to be dumb. ## Feature envy A method suffers **feature envy** when it uses another class's data more than its own - typically pulling three or four getters from the same object and computing something. That is a location error: the computation wants to live in the class it is envying, next to the data it needs. Moving it there removes accessors from the public surface, which is what actually reduces coupling. Not all feature envy is bad. Deliberate cases: a report or export layer that must read many objects, a mapper that translates domain to DTO, and cases where the envied class must remain a pure data structure (an event payload). The judgment: is the logic a *rule of the envied concept*, or a rule of the *caller's* concept that merely reads data? ## Tell, Don't Ask The corrective: **do not ask an object for its state and then decide for it - tell it what to do.** - Ask style: `if (account.getBalance() >= amount) { account.setBalance(account.getBalance() - amount); }` - the rule lives in the caller, repeated everywhere, and the setter can violate it. - Tell style: `account.withdraw(amount)` - the rule lives once, with the data it protects; an overdraft can be rejected by throwing or returning a result type. This is also the deep reason behind the Law of Demeter: train wrecks are usually asking, at depth. Queries are not banned. `account.canCover(amount)` is a legitimate ask if the *decision* it feeds is not the account's business (e.g. UI enabling a button). The line: asking for a *judgment* the object is qualified to make is fine; asking for *raw internals* so you can make its judgment yourself is not. ## Practical remedies 1. **Move Method** to the class whose data is being envied (the standard refactoring). 2. **Replace accessor chains with intention-revealing operations** (`order.shipTo(address)`). 3. **Split the hybrid**: a dumb persistence/DTO record at the edge, plus a behaviour-rich domain object inside; map between them. 4. **Constrain framework-driven setters**: constructor injection, package-private or private setters, or a separate persistence model, so an ORM's requirements do not dictate the domain API. 5. **Delete unused accessors.** Getters exist because someone needed them; if nobody does now, removing them shrinks the surface that hybrids grow on. ## Counter-pressure Tell-Don't-Ask taken to an extreme produces objects that try to do everything, including presentation and persistence - violating single responsibility and making the domain depend on infrastructure. The balanced position: rules about a concept live with that concept; orchestration, I/O, and cross-aggregate coordination live in services that *tell* those objects what to do.