Kinds of Coupling

• The three cheap kinds are checkable by a compiler or a test. The three expensive kinds are exactly the ones that are not (Testing as Design Feedback).
• If a limited budget forces a choice, spend it on shared state first — it is the only kind whose failures are non-deterministic.
• None of these is forbidden. Implementation coupling between two files owned by the same person that always change together is fine, and saying so out loud is better than pretending otherwise (Deliberate Debt).

function publish(post: Post, draft: boolean, notify: boolean, reindex: boolean) {
  if (!draft) { validate(post) }
  save(post, draft)
  if (notify && !draft) { sendSubscriberEmails(post) }
  if (reindex) { search.index(post) }
}

publish(post, false, true, true)
publish(post, true, false, false)
// eight combinations exist, three are meaningful,
// and the caller must know the body to pass them correctly

function saveDraft(post: Post): Draft {
  return store.saveDraft(post)             // no validation, no email, no index
}

function publish(post: Post): Result<Published, ValidationError> {
  const valid = validate(post)             // always — publishing implies valid
  if (!valid.ok) return valid
  const published = store.publish(valid.value)
  events.emit({ kind: 'post-published', id: published.id })
  return ok(published)
}
// notification and indexing subscribe to the event;
// neither is a decision the caller makes

The flags encoded rules that belong to publishing, not to the caller — "drafts are not validated", "drafts do not notify". Moving them inside makes them true everywhere, including at call sites written later, and collapses eight combinations to two operations. The trade is real and worth naming: emitting an event replaces a direct call the compiler could check with an edge no type system sees, so the coupling to indexing did not disappear, it changed kind (Observer). That is an improvement here only because indexing is genuinely optional and independently deployable — if the caller needed the search index updated before returning, the event would be a lie.

1// Coupled to the implementation: this test passes only for one algorithm
2it('charges the customer', () => {
3  const gateway = mock<Gateway>()
4  const audit = mock<Audit>()
5  new Checkout(gateway, audit).pay(order)
6 
7  expect(audit.record).toHaveBeenCalledBefore(gateway.charge)   // an ordering
8  expect(gateway.charge).toHaveBeenCalledWith(order.id, 4200, 'EUR')
9})
10// Moving the audit write into a transaction wrapper breaks this test
11// while the observable behaviour is identical.
12 
13// Coupled to the contract: passes for any implementation that is correct
14it('charges the customer and leaves an audit trail', async () => {
15  const gateway = new InMemoryGateway()
16  const audit = new InMemoryAudit()
17  await new Checkout(gateway, audit).pay(order)
18 
19  expect(gateway.chargesFor(order.id)).toEqual([money(4200, 'EUR')])
20  expect(audit.entriesFor(order.id)).toHaveLength(1)
21})

The first test encodes a call order that nothing in the requirement demanded. Six months later a refactor that preserves every observable behaviour turns the build red, and the engineer doing the refactor has to decide whether the ordering was a rule or an accident — with no way to tell. That decision cost, paid by someone who was not in the room, is what implementation coupling actually charges (Test Doubles, Precisely).