Why model an at-most-one lookup result as a dedicated empty-or-one-value context rather than a list holding zero or one element?

## The two representations An employee has at most one manager. Two ways to express the result of looking that manager up: - **A zero-or-one collection.** The lookup returns a sequence that is either empty or holds one record. Transformations over it behave the way you want for free: a map over an empty sequence does nothing, a filter narrows it, and joining several lookups flattens naturally. - **A dedicated at-most-one container.** The lookup returns a value that is either empty or holds exactly one record, with no notion of size, order or position at all. Both carry absence as a value rather than as a missing reference, so both avoid the problem this leaf is really about. The question is what each one *additionally* says. ## What the collection admits The collection type says `zero or more`. The domain says `zero or one`. That gap is representable state: nothing in the type prevents a second manager from being in there, so every reader has to establish by argument that it cannot happen, and every defensive coder eventually writes the check. ``` managers = directory.findAll(employee.managerId) // zero, one, or more? if managers.size > 1 // what would this even mean? desk = managers.first().desk // and this fails when empty ``` The first branch is dead code that looks prudent. The last line reintroduces exactly the hazard the representation was meant to remove: `first` has no answer on an empty sequence, so the empty case is back, now wearing a position. ## What the reading step becomes | | zero-or-one collection | at-most-one container | |---|---|---| | what the type admits | zero or more elements | zero or one value | | reading the value | take a first element, handle empty | transform inside, or fall back | | a second element | representable; must be ruled out | not constructible | | what a reader must verify | that more than one cannot occur | nothing beyond the two cases | | natural exit | another collection | a value, via one fallback | The row that matters most is the third. Making a wrong state impossible to construct is stronger than making it unlikely, because the argument never has to be repeated - not in review, not after a refactor, not by the next person who calls the function. ## When the collection form is the better choice This is a genuine trade-off, not a rule, and the honest answer names the case where the collection wins. If the result is about to join many other results - desks for a whole department - then a per-employee collection flattens into the final collection with no conversion step at all, and a container would have to be unwrapped into one first. Pipelines whose end product is a collection are more uniform when every stage is a collection. The moment the value is consumed on its own, that uniformity turns into noise: the reader has to establish the cardinality again, the exit is a first-element access, and a bug that produces two rows becomes a silent wrong answer rather than a type error. ## A note on the other direction The same reasoning runs backwards, and it is worth saying: modelling a genuinely zero-or-many result as an at-most-one container is the same defect mirrored. The type would then forbid a state the domain has, so code would start dropping records or raising on the second one. The principle is not `prefer the container`; it is **make the type say exactly the cardinality the domain has**, no more and no less. ## What an interviewer listens for A weak answer reaches for performance - the container allocates less, the collection is slower - which is not the point and usually is not even true in any way the caller can measure. The answer that lands is about what the type admits: the collection permits a state the domain excludes, so the exclusion has to be argued rather than guaranteed, and the read becomes positional. Finishing with the case where a collection is the right call, and with the mirrored version of the mistake, is what turns it from a memorised preference into judgment.