Software Design & Object Modelling

What a type checker actually buys you and what it costs — the static/dynamic and strong/weak axes that get conflated, soundness and the places real languages deliberately break it, gradual typing, and the measured effect on bug rates.

What assignment and argument passing actually do, why "Java passes objects by reference" is false, how aliasing turns into bugs, and the memory-layout consequences that make this a performance decision as much as a correctness one.

Widening and narrowing conversions, implicit coercion and the comparison tables it produces, why casting and parsing are different operations, and the failure modes — silent truncation, locale-dependent parsing, and type-juggling authentication bypasses.

Why a null that inhabits every type defeats the type system, what Option/Maybe buys and costs, how Kotlin, C#, Rust and Java each retrofitted or avoided it, and the traps that survive — platform types, typed nils, and SQL's three-valued logic.

Parametric polymorphism and what it costs at run time — erasure versus reification versus monomorphization — and variance: why a list of dogs is not a list of animals, and how PECS, declaration-site variance and use-site wildcards each express the same rule.

Why encapsulation is about invariants no external code can break rather than about private fields, why the getter/setter pair defeats it, and how interface width versus functionality — deep versus shallow modules — decides whether hiding actually bought anything.

Inheritance bundles three separate things — subtyping, code reuse and open recursion — and the fragile base class problem comes from the bundling; when composition and delegation are the right default, and the narrow cases where a hierarchy is still correct.

The four kinds of polymorphism and which are resolved when — overload resolution on static types, virtual dispatch through vtables and itables, what JIT devirtualization and inline caches actually do, and when the indirection is worth measuring.

What an interface promises beyond its signatures, who should own it — the implementer or the caller — the real differences between interfaces, abstract classes and traits, and why an interface with exactly one implementation and one mock is usually a mistake.

The five SOLID principles are of very unequal value — Liskov substitution is a checkable property with a formal definition, dependency inversion is a structural rule about module boundaries, and the other three are heuristics that routinely get applied backwards.

Getting an object fully valid before anyone can see it, why garbage collection manages memory but not resources, and the deterministic release mechanisms — RAII, Drop, IDisposable, try-with-resources — plus the finalizer patterns that look like a safety net and are not.

What immutability actually guarantees — free thread-safety, safe sharing, valid hash keys — what it costs in allocation and how persistent structures and copy-on-write reduce that cost, and why a domain value object beats a primitive for money, identifiers and quantities.

How errors travel and whether the type system forces you to deal with them — checked exceptions, Result and Either, Go's explicit err — plus the distinction between recoverable errors and bugs, the real cost of throwing, and the anti-patterns that turn a failure into silence.

Who is responsible for checking what — design by contract's split between preconditions, postconditions and invariants — why assertions and input validation must never be the same mechanism, and why parsing at the boundary beats validating everywhere.

How signatures and equations specify abstract data types, when equations can execute as rewrite rules, and which termination, confluence, and semantic obligations make algebraic program transformations trustworthy.

What each format actually encodes and what it silently drops, why language-native serializers are a remote-code-execution surface rather than a convenience, and when canonical encoding, zero-copy access or a real schema is the requirement.

Backward, forward and full compatibility stated precisely, the concrete rules for changing a Protobuf, Avro or JSON contract without breaking a deployed peer, and expand–contract as the general recipe for changing anything two versions must agree on.

Which of the GoF patterns became language features, which are still real design decisions, and how to read a pattern as a symptom — a workaround for something the language or the architecture is missing.

The observer pattern's real costs — leaked subscriptions, reentrancy, unbounded fan-out, and the loss of a readable call stack — and what changes when events go from in-process callbacks to a durable log.

Three things that get merged under one name — the dependency inversion principle, injection as a technique, and IoC containers as a tool — plus why constructor injection wins, what a container actually costs, and why service location hides what injection reveals.

How layered monoliths, microkernels, microservices, event-driven systems, and space-based grids constrain deployment, communication, state, scaling, and failure — and how to choose and combine them from concrete quality-attribute scenarios.

The twelve factors are best understood as a system of deployment boundaries—source, artifact, config, release, process, state, and platform—not as a complete cloud-native checklist or a demand to use one particular tool.

Why packaging by technical layer makes every feature change touch every package, what the dependency rule in hexagonal and clean architecture actually enforces, and why a boundary the build does not check is only a diagram.

Designing an interface that is hard to misuse, why every observable behaviour becomes part of the contract whether you documented it or not, what semantic versioning can and cannot promise, and how to remove something without breaking the people using it.

The small subset of UML that survived — class, sequence and state diagrams — what each is actually good at, why model-driven code generation failed, and why diagrams that live in a wiki rot while text-based ones in the repo do not.