ACID, SOLID, and Design Patterns: A Complete Software Design Reference

Part 1 of 26 · ~1 min

Overview

People usually meet these three in three different classes, taught by three different people, and walk away thinking they're three different subjects. They're not. They're the same concern — what happens when this thing changes — enforced at three different distances from the database. ACID is the guarantee the database engine makes to you, unconditionally, the moment you write COMMIT. SOLID is the guarantee a well-shaped class makes to the rest of your codebase, and it only holds if you actually shape the class that way. Design patterns are just the handful of shapes people keep reaching for to make that second guarantee true in practice, instead of re-inventing the same shape badly every time it's needed. Read it as a reference, not a five-minute skim — start to finish if you're building the whole picture, or straight to one chapter from the sidebar if you already know what you're after. Every object-oriented snippet from here on is written in C#, simply because it's the language this kind of material and this kind of interview question most often shows up in. Nothing about the ideas themselves is tied to the language, though — hand the same class to a Kotlin, Java, or TypeScript developer and every principle and every pattern still applies exactly as written, syntax aside.