skip to content

You set the extension contract for add-in teams that cannot depend on your code — do you require a published supertype or a shape?

level: principalimportance: should knowfreq 40%

answer

  1. what does the contract carry
  2. who can afford the dependency
  3. can you enumerate the conformers
  4. adapters versus external conformance records
  5. member names become public surface

basics

~20 s

Decide by what the contract carries. Behaviour, ordering and a need to enumerate and notify conformers argue for a published supertype with host-supplied adapters; reach across teams who cannot take the dependency argues for a shape, kept narrow, plus published conformance tests.

solid answer

~40 s

The question is not which rule is better but what your extension point is made of. If the contract is mostly behavioural — ordering, lifecycle, invariants — require a published supertype: the declaration is where documentation, versioning and accountability live, and it gives you a list of conformers to notify before you change anything. If reach matters more, because add-ins are pre-existing types owned by teams who cannot take a dependency on your release train, require a shape, keep it narrow enough to read and wide enough not to match by accident, and publish an executable conformance suite because the shape settles members and nothing else. The honest answers are usually hybrids: a small published supertype with adapters you ship, or a shape carrying one operation over a type you publish.

go deeper

for a junior

Recall that an extension point can require a published type to be implemented or merely a set of operations, and that the choice decides who can write an add-in.

for a middle

Explain the trade in both directions: the reach a shape buys, the dependency edge a named requirement forces, and the adapter that bridges them.

for a senior

Argue the choice for a concrete extension point, including how you would add an operation to the requirement later and what each world lets you do about it.

for a principal

Own it as a cross-team commitment: who may extend you, whether you can ever enumerate and warn conformers, which hybrid you standardise on, and what you publish so behaviour is checked at all.

## State the decision properly "Named or structural" sounds like a type-system preference. It is an organisational commitment, and it is easiest to see on a plugin host in a build system, where add-ins come from teams that may not be able to depend on your code at all. Choosing the rule decides who can extend you, who must change to do it, and who you can reach when the contract moves. Three questions settle most of it: 1. **What does the contract actually carry** — a couple of operations, or behaviour, ordering and lifecycle guarantees? 2. **Who will implement it** — types written for you, or types that already exist? 3. **Will you need to enumerate conformers** — for a deprecation sweep, a security notice, a breaking change? ## What pushes you toward a published supertype - The contract has **invariants and ordering** that prose must explain; the declaration is the only place to attach that prose, its version and its examples. - You need a **list of conformers**. Declared conformance can be searched; a shape match cannot, so a migration turns into an announcement and a hope. - Accidental matching would be **expensive** — the operation moves money, deletes artifacts, or decides whether a build is reproducible. - Add-in authors are inside your dependency boundary anyway, so the edge costs them nothing they were not already paying. ## What pushes you toward a shape - Candidates are **pre-existing types** you want to accept unchanged; retroactive conformance is the shape's one irreplaceable property. - Teams **cannot take the dependency** — different release cadence, a policy against depending on your layer, or your artifact is the heavier one. - The contract is genuinely **thin**: read this, name that, and nothing about ordering. - You want add-ins to be testable in isolation without linking your artifact at all. ## Hybrids that are not a fudge 1. **Small supertype, host-supplied adapters.** Keep the named requirement and absorb the retroactivity cost yourself by shipping wrappers for the common pre-existing types. Intent stays explicit; you pay per adapted type and you become the one who notices when the adapted type changes. 2. **Shape plus one anchoring operation.** Require mostly a shape, but let one required operation return a type you publish — a capability or protocol descriptor. Accidental matching becomes very unlikely and intent returns, at the price of the dependency edge on that one operation. 3. **Conformance declared outside the type.** Where the platform offers it, a standalone record can state that an existing type satisfies a published requirement, giving retroactivity without an edit and keeping the requirement named. Decide up front **who owns the record** — the host, the add-in team, or a third party — because two competing records for the same pair is the failure mode of this mechanism. 4. **Two tiers.** A shape for the read-only surface, a named supertype for the part that mutates state or participates in the lifecycle. ## What you owe the teams either way 1. A requirement narrow enough that its rejection messages stay short and actionable. 2. An executable conformance suite, because no form of requirement checks meaning. 3. A stated policy for adding an operation to the requirement — it breaks conformers in both worlds; only the named world lets you warn them first. 4. Under a shape, a commitment about member **names**: they are now your public surface, and renaming one is a breaking change even though nobody named you. ## The costs to say out loud | Commitment | Named supertype | Shape | |---|---|---| | Who can extend you | teams able to take the edge | anyone whose members line up | | Retroactive conformance | adapter or external record | free | | Notifying conformers | possible | not possible | | Matching by accident | excluded | possible, mitigated | | Your ongoing cost | adapters and the published type | conformance tests and name stability | ## What an interviewer is listening for - That you ask what the contract carries before you answer, rather than picking a side. - That you treat enumerability as a first-class consequence, not a detail — it is what a migration lives on. - That you name a hybrid and its price, since the price is always a dependency edge somewhere. - That you separate what a requirement can settle (members) from what only tests settle (behaviour), and commit to both.

  • You chose a shape and now need to add a required operation. What is the migration actually like?
    Blind. Every conformer breaks at its next build, and you cannot list them, because nothing they wrote points at you. The realistic play is to publish the widened requirement alongside the old one, accept either for a period, and announce through channels rather than through the type system. A named requirement gives the same break with a list of people to warn.
  • What does conformance declared outside the type buy, and what does it cost?
    It buys retroactive conformance with intent intact: an existing type satisfies a published requirement without being edited, and the requirement stays named, documented and versioned. It costs coherence. If two parties can each declare a record for the same type and requirement, something must decide which applies, so ownership of the record has to be settled in the contract, not discovered later.
  • Why is publishing conformance tests necessary under either rule?
    Because neither rule checks behaviour. A shape settles which members exist; a named supertype settles who agreed to the contract. Both accept a conformer that returns the wrong sign or mutates what it promised to leave alone. An executable suite the candidate's own build runs is the only gate that tests meaning, and it is the one thing you can hand to a team you cannot enumerate.

saying these in an interview costs you the question

  • Picks a rule without asking what the contract carries.
  • Claims a shape removes coupling instead of moving it to member names.
  • Assumes conformers under a shape can be enumerated for a migration.
  • Treats adapters as free rather than as maintenance you own.
  • Believes a published supertype makes conformance tests unnecessary.