Structural Typing & Duck Typing

interface Point { x: number; y: number; }
class Vector { constructor(public x: number, public y: number) {} }
function printPoint(p: Point) { console.log(p.x, p.y); }
printPoint(new Vector(1, 2)); // works! Vector has the same SHAPE as Point, despite no declared relationship

Common follow-ups: What's the common phrase used to describe this kind of shape-based compatibility, borrowed from Python?

interface Quacks { quack(): void; }
function makeItQuack(thing: Quacks) { thing.quack(); }
makeItQuack({ quack: () => console.log('Quack!') }); // works -- has the right shape, no formal 'Duck' type needed

Common follow-ups: Does this mean you never actually NEED to use 'implements' in TypeScript for structural compatibility to work?

interface Point { x: number; y: number; }
function printPoint(p: Point) { console.log(p.x, p.y); }
printPoint({ x: 1, y: 2, z: 3 }); // Error: object literal has excess property 'z'

const obj = { x: 1, y: 2, z: 3 };
printPoint(obj); // OK! Assigned via a variable, so excess property checking doesn't apply

Common follow-ups: Why does excess property checking specifically NOT apply when the object comes from a variable instead of a literal?

interface Named { name: string; }
interface Labeled { name: string; }
function greet(entity: Named) { console.log(entity.name); }
const item: Labeled = { name: 'Widget' };
greet(item); // works fine, despite 'Labeled' having no declared relationship to 'Named'

Common follow-ups: Does this same interchangeability apply if the two types have PRIVATE members with the same names, as covered in the Classes topic?

type Callback = (a: number, b: number) => void;
const shortFn: Callback = (a) => console.log(a); // OK -- fewer params is fine
// const longFn: Callback = (a, b, c) => console.log(a, b, c); // Error: too many required params

Common follow-ups: Why is this particular asymmetry considered safe from a pure function-call perspective?

type UserId = string & { readonly __brand: 'UserId' };
type ProductId = string & { readonly __brand: 'ProductId' };

function createUserId(id: string): UserId { return id as UserId; }
function getUser(id: UserId) { /* ... */ }

const pid = 'p123' as ProductId;
// getUser(pid); // Error: ProductId is not assignable to UserId, despite both being strings

Common follow-ups: What's the runtime cost (if any) of using branded types, given the brand property doesn't actually exist on real string values?

interface Greetable { greet(): void; }
class Person {
  greet() { console.log('Hi'); }
  walk() { console.log('Walking'); } // extra method, not required by Greetable
}
const g: Greetable = new Person(); // OK -- Person satisfies AND exceeds Greetable's shape

Common follow-ups: How does this relate to the Interface Segregation Principle from object-oriented design?

interface Options { timeout?: number; }
interface Empty {}
const e: Empty = {};
const opts: Options = e; // OK -- Empty structurally satisfies Options, since 'timeout' is optional

Common follow-ups: Would this same assignment succeed if 'timeout' were a REQUIRED property instead of optional?

interface Comparer<T> {
  compare(a: T, b: T): number;      // method syntax: bivariant, more lenient
  compareArrow: (a: T, b: T) => number; // arrow property: contravariant, stricter with strictFunctionTypes
}

Common follow-ups: How does the 'strictFunctionTypes' compiler option specifically affect this bivariance for standalone (non-method) function types?

interface Logger { log(message: string): void; }
class ProductionLogger implements Logger { log(m: string) { /* sends to real service */ } }
class FakeLogger implements Logger { logs: string[] = []; log(m: string) { this.logs.push(m); } }

function doWork(logger: Logger) { logger.log('working...'); }
doWork(new FakeLogger()); // trivially swappable in tests, thanks to structural typing

Common follow-ups: How does this structural-typing-driven design relate to the Dependency Inversion Principle from SOLID?