What does a mapper typically demand of a mapped class, and what does each demand cost encapsulation?

A mapped class is not an ordinary class. To turn a row into an object and an object's changes back into statements, a data-access layer has to do things to the instance that no other caller does, and it states those needs as requirements on the type. Knowing the list matters because each item is a small concession by the class, and together they decide how much of your design survives contact with persistence. ## What the layer has to do, and therefore needs Materialising an object from a row is not a normal construction. The layer has the values, but it does not know which constructor to call, in what order the parameters go, or how to satisfy a constructor that itself performs work. So it takes the simplest available route: create an instance, then populate it. 1. **A construction path that takes no arguments.** The instance is created empty and filled member by member. Many layers accept a non-public one, which keeps it out of the public surface but does not remove it. 2. **Readable and writable members.** Values must be pushed in on load and pulled out on flush. 3. **Classes and members open to substitution.** A layer that defers loading behind a stand-in, or notices changes by intercepting access, hands out a generated subclass of your type. Sealing the class or its mapped members blocks that. 4. **Collections it can own.** A collection you assign in a constructor is generally discarded and replaced by the layer's own tracked implementation, so it can record additions and removals. ## What each demand costs | Demand | Why the layer needs it | What it costs the class | |---|---|---| | No-argument construction | Build first, populate after | The class can exist half-built; a constructor cannot be the only way in | | Direct member access | Push loaded values in, read changes out | Validation living in setters can be bypassed, or run at surprising times | | Open to subclassing | Deferred loading and change interception | The type cannot be sealed; equality and type checks must tolerate a subclass | | Owned collections | Track additions and removals | The instance you supplied is not the instance you get back | ## Field access versus accessor access Most layers let you choose whether values move through fields directly or through accessors, usually per class. The choice is not cosmetic. **Accessor access** means your logic runs during load and during flush: a setter that normalises input will normalise data coming out of the database, and a getter that computes lazily may be called by the layer at unexpected moments. **Field access** bypasses that logic entirely, which is usually what you want for round-tripping stored data, but it means a value can be written that the accessors would have rejected. Choose deliberately, and expect defensive logic in accessors to behave differently under each. ## The collection substitution The collection swap surprises people the most. Patterns that break: - **Identity comparison.** Code holding on to the collection instance it passed in finds the object is no longer that instance. - **Defensive copying on read.** Returning a copy of a tracked collection is fine, but mutating the copy records nothing, so the change is silently lost. - **Wholesale replacement.** Assigning a brand-new collection over a tracked one discards the tracking, and layers differ on whether they cope with it gracefully. - **Immutable collections.** A collection type that cannot be mutated cannot be tracked, so the layer has nothing to record against. ## Layers that demand less Not every data-access layer imposes this list. A layer that materialises through a constructor and does no change tracking can accept fully immutable types with no empty construction path at all: it reads rows into new objects and you write updates explicitly. The demands above come with the conveniences — deferred loading, automatic change detection, a tracked set that flushes on its own. That is the honest framing of the trade: the requirements are the price of the automation, not an accident of implementation. ## Living with the demands Practical mitigations, in rough order of cost: - Keep the no-argument construction path non-public so ordinary callers cannot reach it, and keep the real constructor as the one meaningful entry point. - Put invariants that must always hold in the operations that change state, not only in the constructor, since the constructor can be bypassed. - Do not rely on the identity of a collection you assigned; expose the collection through operations that add and remove rather than handing it out. - If the demands genuinely conflict with the design — an immutable type with a rich constructor, for instance — that is the argument for translating between a domain type and a separate persistence type at the boundary, which trades these concessions for translation code.