'Closure of operations' is a Supple Design pattern where an operation's return type is the same type as its arguments -- for example, Money.add(Money other): Money rather than Money.add(Money other): BigDecimal. What problem does this solve, and when does forcing closure actually hurt the design?

## What closure means **Closure of operations** is a narrower, specific pattern within side-effect-free functions: design an operation so its return type is the same type as its operand(s), the way `Money.add(Money other): Money` returns another `Money` rather than a raw `BigDecimal`, or `Set<T>.union(Set<T>): Set<T>` returns another `Set<T>` rather than some intermediate collection type. Mechanically, applying it means checking, for each operation on a type, whether the natural result can be expressed as an instance of that same type or a type in the same closed family, and if so, returning that instead of unwrapping into a more primitive representation. ## Why it pays This exists for two compounding reasons. 1. **First, composability**: if `add` returns `Money`, you can chain further operations directly, such as `price.add(tax).add(shipping).subtract(discount)`, without any intermediate conversion step, the same way integer addition returns another integer you can keep adding to. If it returned `BigDecimal` instead, every chained call would need an explicit re-wrap back into `Money`, defeating the purpose of having a `Money` type at all. 2. **Second, encapsulation**: `Money` typically enforces invariants a raw number doesn't -- currency matching, rounding mode, maybe a minimum denomination -- and returning the domain type instead of a primitive means every consumer of the result automatically continues to benefit from those guarantees instead of having to re-derive or forget them. ## Where the pattern stops fitting The pattern doesn't always fit. - Some operations naturally lose information going back into the same type -- `Money.divide(3): Money` on a ten-dollar amount divided three ways can't return three exact `Money` values without a rounding rule, so the type either needs an explicit remainder-aware division method or accepts a rounding policy as part of the contract, which is more design work than a naive same-type return. - More importantly, not every operation's true result is conceptually the same kind of thing as its inputs, and forcing closure onto those cases produces an **overly permissive type** -- the cost of a badly-fitted closure is hidden illegal states that the type system can no longer prevent. ## Failure modes The clearest failure mode is exactly that: modeling `Order.cancel(): Order`, returning the same order marked cancelled so it 'looks closed' like `Money.add()`, means nothing in the type system stops a caller from later calling `cancelledOrder.ship()` -- the type still claims to be a full, live `Order` with every operation available, when semantically a cancelled order shouldn't support most of them. The bug that results, shipping something that was cancelled, only gets caught by a runtime check, if at all, rather than being impossible to write in the first place. Another failure mode appears with mutable receivers: a team notices `add()` is 'returning the same type' and decides to skip allocating a new instance, mutating the receiver instead and returning void -- which breaks the immutability that made chaining safe in the first place, since two variables that supposedly hold 'the price before tax' and 'the price after tax' can now silently become the same mutated object. ## Genuine closure versus a missing type - `Vector2D.add(Vector2D other): Vector2D`, implemented to allocate and return a new immutable `Vector2D` rather than mutating either operand, is the pattern working correctly: `a.add(b).add(c)` reads naturally, no operand is silently changed underneath a caller holding a reference to it, and the whole family of vector operations can be composed freely. - Contrast that with `Order.cancel()`: the correct application of Supple Design here isn't to force closure but to recognize the domain actually has two related-but-different concepts -- introduce a distinct `CancelledOrder` type, or a sealed hierarchy with `Order` as a sum type of `ActiveOrder`, `CancelledOrder`, and `ShippedOrder`, so the compiler, not a runtime check, prevents `ship()` from ever being called on something that's already cancelled. Recognizing which of these two situations you're in, genuine closure versus a missing type, is the actual skill the pattern requires.