SOLID Principles

## The question behind the question SOLID was written down about class-based, single-inheritance languages — Smalltalk, C++, Java, C#. Carried into Go, Rust, Elixir, or a TypeScript codebase built from functions and records, it usually gets one of two lazy treatments: "that's object-oriented dogma, ignore it," or a rote application that produces single-type packages and interfaces nobody consumes. The useful move is mechanical. For each principle ask: *what language feature does this actually spend?* Four of the five spend something any modular language already has. One spends implementation inheritance — and only in its wording, not in its intent. ## Single responsibility — spends a unit of change The principle says a module should have one reason to change. "Module" is deliberately unspecified; the paradigm supplies the candidate noun. In class-based languages the candidate is the class, which is why the textbook example is a class that both formats a report and stores it. In Go the compilation and visibility unit is the package, and idiomatic Go puts several small types sharing one job into one package; applying the rule per type there produces one-type packages and import churn nobody wants. In Erlang or Elixir the unit is the module, or a supervised process. Nothing about the principle changes — the noun it quantifies over changes. If you don't re-pick that noun deliberately, you import another language's granularity along with the rule. ## Interface segregation — spends interfaces, nothing more Splitting one fat contract into several narrow ones needs an interface mechanism and nothing else: no classes, no base types, no inheritance. It therefore carries over to Go and Rust untouched. What differs between languages is only the *price* of a narrow contract, and that price is set by who declares conformance — near zero where the consumer declares a small structural interface right beside the function that takes it (Go's convention), a source edit in every implementer and every test double where the implementer must declare conformance. Same principle either way; in one dialect it is a discipline you must remember, in the other it is the path of least resistance. ## Dependency inversion — spends indirection at the call site The principle asks that high-level policy name an abstraction rather than a concrete detail. *Any* mechanism that lets a call site name something other than a concrete type satisfies it: an interface, a trait, a protocol, a function value, a duck-typed parameter. Inheritance is not on that list, so the principle is untouched by its absence. Rust makes the engineering choice unusually visible because it offers two implementations of the same indirection, with different bills. A trait object (`&dyn Trait`, `Box<dyn Trait>`) erases the concrete type behind a vtable: dispatch is an indirect call, the binary holds one copy of the code, and a single `Vec<Box<dyn Trait>>` can hold several different implementations at once. A generic parameter (`fn run<T: Trait>(t: T)`, or `impl Trait` in argument position) is monomorphized — the compiler emits a specialized copy per concrete type, dispatch is static and inlinable, runtime cost is nil, binary size and compile time grow, and one `Vec<T>` can only ever hold a single implementation type. Both are dependency inversion. Neither is more "correct"; you pick per call site, on whether you need heterogeneous storage or a runtime-selected implementation (trait object) or a hot monomorphic path (generic). Languages without that fork simply have the choice made for them — a Java interface call is always the erased, vtable-shaped one. ## Open/closed — the one whose wording must be restated The familiar formulation — "open for extension, closed for modification: add a subclass rather than editing the class" — is a statement about implementation inheritance, and neither Go nor Rust has it. Extension there means defining a new type and giving it an impl of an existing trait, or writing a new function over an existing interface. Behaviour *reuse*, which the base class used to supply for free, comes from embedding (Go) or default trait-method bodies (Rust) instead. The restated, durable version is: *depend on an abstraction so new participants can be added without editing the code that consumes them.* The subclass was always the accident; the stable consuming code was always the point. ## Liskov substitution — survives as intent, loses its scaffolding In a subclassing language the compiler enforces a skeleton of substitutability: signature compatibility, covariant returns, no narrowing of access, variance rules on generics. Remove subclassing and that skeleton disappears. A Go type satisfying an interface has agreed to method names and shapes and to *nothing else*; a Rust impl has agreed to the trait's signatures. Preconditions, postconditions and invariants — the actual content of Liskov — are unchecked in every language, but here even the shape checks stop implying a hierarchy. So substitutability becomes purely a behavioural contract, and the practical recovery is a *contract test suite*: one shared set of tests written against the interface that every implementation must pass, plus property-based tests for the invariants prose can't pin down. ## What the mapping is worth Two payoffs. First, it tells you what to re-pick when you change languages: the noun for single responsibility, the wording for open/closed, and the enforcement story for Liskov — the rest transfers verbatim. Second, when someone says "SOLID doesn't apply to Go," the accurate reply is that four of the five apply so cheaply they stop being visible as advice, and the fifth is phrased around a mechanism the language does not have. ## How to answer in an interview Don't recite five definitions — that is table stakes. Name the mechanism each one spends, then name a language where that mechanism is absent or free and say what changes. The strongest single beat is the Rust one: the same dependency inversion has two prices, chosen per call site, which shows you treat the principle as a design constraint rather than a syntax habit.