When do you stop adding mixins to a Python class and delegate to a collaborator object instead?

## Both mechanisms share behaviour; they differ in what they cost - A **mixin** adds capability by inheritance: the methods appear on the instance, there is no forwarding code, and callers see one flat surface. - A **collaborator** adds capability by holding another object and calling it: construction becomes explicit, the piece is separately testable and replaceable, and someone has to write the forwarding. The judgement is not about which is purer — it is about which cost this codebase can afford where. ## Threshold one: shared namespace Every base of a class writes into the same `self`. Two mixins from two teams that each keep `_cache`, `_retries` or `_log` silently overwrite one another, and neither file mentions the other, so no reviewer of either change can see the collision. There is no namespacing mechanism to fall back on: unlike a collaborator, whose state lives behind its own attribute, mixin state is pooled by construction. Prefix conventions and name mangling reduce accidents but do not make the pooling go away. ## Threshold two: undeclared contracts A mixin that reads `self.session` or calls `self.emit()` without defining either has a contract with its host that exists only in its author's head. It works until someone mixes it into a class that has no `session`, or into one whose `emit` means something else. A collaborator has to be handed its dependencies through its own `__init__`, so the contract is written down where the object is constructed, and a missing piece fails at wiring time instead of on an unusual code path in production. ## Threshold three: variability Bases are fixed when the class object is created. That makes a mixin the wrong tool whenever the behaviour must vary: - a different implementation per environment, - a null implementation in tests, - two policies chosen at startup. Achieving that with inheritance means building classes dynamically or carrying a flag inside the mixin, both of which are worse than the collaborator that simply gets passed a different object. If the answer to *can this be swapped* is yes, it is an object. ## The recurring tell A mixin that grows an `__init__` has usually outgrown the pattern. Now every host must cooperate in construction and pass the right arguments through the chain, which means the class that wanted one capability has taken on an ordering obligation. At that point the behaviour has its own state and its own lifecycle, which is the definition of a thing rather than a trait. Two more tells: - a mixin used by exactly one class is just code in the wrong file, - and a mixin that can only be tested by composing an increasingly elaborate host class is telling you how big its hidden contract really is. ## What delegation costs, honestly Forwarding methods are real work and real noise, and reaching for a catch-all attribute-forwarding hook to avoid writing them is a blunt instrument: it forwards names you never intended, confuses tooling and introspection, and turns a typo into a silent miss. Delegation also moves the capability off the instance's own surface, so callers write `loader.cache.stats()` instead of `loader.stats()`, and existing call sites have to change. Where the behaviour is genuinely small, stateless and universal, paying that cost buys very little — which is why the pattern is worth keeping rather than abolishing. ## A workable policy - **Mixins** for small, stateless, cross-cutting capability wanted by several classes that share no other ancestor, with the required host contract declared as abstract methods rather than assumed, and a cap on how many any one class carries — past three or four, nobody can predict the combined behaviour from the class statement alone. - **Collaborators** for anything with state, configuration, a lifecycle, more than one implementation, or a need to be replaced in a test. - The middle case, a capability wanted by many classes *and* carrying state, is best served by a thin mixin that holds no state itself and simply forwards to a collaborator the host constructs — the flat call surface without the pooled namespace. ## The organisational angle a lead owns A wide mixin vocabulary is a shared language: every mixin multiplies the combinations reviewers must reason about, and the interactions are invisible at every call site because they live in a bases tuple. Collaborators scale differently — more objects, more wiring, but each one comprehensible alone. Which cost dominates depends on how many people touch these classes and how confidently they can be tested, and that judgement, not a slogan, is what an interviewer is listening for.