Design Principles
Rules of thumb for structuring code that stays changeable.
5 subjects · 42 topics · 3 areas · 1 cheatsheet
Subjects covering this category
5 subjects- Subject · Beginner to Advanced
Recognising the 23 classic design patterns from a class diagram or from code, and implementing each in Python, Java and TypeScript.
- Foundations
- Creational Patterns
- Structural Patterns
- Subject · Beginner to Advanced
Recognising object-oriented code that will be hard to change, and restructuring it with the five SOLID principles.
- Design Rot and the Five SOLID Principles
- Single Responsibility Principle
- Open/Closed Principle
- Subject · Beginner to Advanced
Writing Java that compiles, runs, and models a problem with objects.
- The Language
- Objects
- When Things Go Wrong
- Subject · Intermediate to Advanced
Holding data in the right Java collection, and transforming it without writing a loop.
- Collections
- Pipelines
- Subject · Beginner to Advanced
Wiring a Java application together with Spring's IoC container, instead of doing it by hand.
- Why Spring Exists
- The Bean and the Container
- Wiring Beans Together
Cheatsheets
1 cheatsheet- Cheatsheet · Java Collections and Streams
Every everyday Java collection on one page: what each one is for, what it costs, and how to choose.
SOLID Principles
7 topics- SOLID Principles
Design rot and the SOLID principles: why working object-oriented code becomes hard to change, and the five principles that answer it.
Beginner to Intermediate9 cards · 7 qnot started
- SOLID Principles
The Liskov substitution principle in SOLID: a subclass must work anywhere its parent does, keeping every promise the parent makes.
Beginner to Intermediate9 cards · 5 qnot started
- SOLID Principles
The dependency inversion principle in SOLID: make business rules depend on abstractions they own, so databases and services can be swapped and faked in tests.
Beginner to Intermediate9 cards · 5 qnot started
- SOLID Principles
The single responsibility principle in SOLID: give each class one reason to change, by splitting it along the people who ask for changes.
Beginner to Intermediate8 cards · 4 qnot started
- SOLID Principles
The open/closed principle in SOLID: add new behaviour as new code, without editing classes that already work.
Beginner to Intermediate8 cards · 4 qnot started
- SOLID Principles
The interface segregation principle in SOLID: give each client a small interface holding only the methods it calls.
Beginner to Intermediate8 cards · 4 qnot started
- SOLID Principles
Applying the SOLID principles together: diagnosing a class that breaks several, refactoring it safely behind tests, and knowing when to stop.
Intermediate to Advanced7 cards · 5 qnot started
Dependency Injection
2 topics- Spring Core
Wiring beans together: constructor injection, stereotype annotations, choosing between two candidates, and @Bean methods.
Intermediate to Advanced7 cards · 5 qnot started
- Spring Core
Dependency injection: why a class should be handed its dependencies instead of creating them, shown without Spring first.
Beginner5 cards · 4 qnot started
Composition
1 topic- Java
Java encapsulation: private fields, the four access levels, references that leak through getters and constructors, and composition against inheritance.
Intermediate to Advanced8 cards · 5 qnot started
In Design Principles itself
32 topics- Design Patterns
The Factory Method pattern: letting subclasses decide which class of object to create, so the code that uses the object never names it.
Intermediate to Advanced9 cards · 4 qnot started
- Design Patterns
The Builder pattern: constructing a complex object step by step, so a constructor with a dozen optional parameters is never needed.
Intermediate to Advanced9 cards · 4 qnot started
- Design Patterns
The Singleton pattern: guaranteeing a class has exactly one instance with a global access point, and why it is the most criticised of the 23.
Intermediate to Advanced9 cards · 4 qnot started
- Design Patterns
The Proxy pattern: a stand-in with the same interface as a real object that controls when and whether calls reach it, and the self-call it never sees.
Intermediate to Advanced9 cards · 4 qnot started
- Design Patterns
The Strategy pattern: putting each interchangeable algorithm behind one interface so the caller chooses it, and why in Python the strategy is often a function.
Intermediate to Advanced9 cards · 4 qnot started
- Design Patterns
The Observer pattern: letting many objects subscribe to one and be told when it changes, and the listener that is never unsubscribed.
Intermediate to Advanced9 cards · 4 qnot started
- Design Patterns
The Command pattern: turning a request into an object that can be queued, logged or undone, and what each command must remember to undo itself.
Intermediate to Advanced9 cards · 4 qnot started
- Design Patterns
The Template Method pattern: fixing the order of an algorithm's steps in a base class and letting subclasses supply the steps that differ.
Intermediate to Advanced9 cards · 4 qnot started
- Design Patterns
The Iterator pattern: walking a collection one element at a time without knowing how it is stored, and why a Python generator can be walked only once.
Intermediate to Advanced9 cards · 4 qnot started
- Design Patterns
The Visitor pattern: adding operations over a fixed set of classes as separate visitor classes, how double dispatch finds the right method, and why a new element class is costly.
Intermediate to Advanced9 cards · 4 qnot started
- Design Patterns
What design patterns are: named, reusable solutions to recurring object-oriented design problems, how the 23 classic ones are grouped, and when one costs more than it saves.
Beginner to Intermediate8 cards · 5 qnot started
- Design Patterns
The Abstract Factory pattern: creating whole families of related objects through one interface, so a program can switch every product at once.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
The Prototype pattern: creating new objects by copying a configured one, and the shallow copy trap that comes with it.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
The Adapter pattern: wrapping an existing class so it fits the interface a client already expects, without changing either side.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
The Decorator pattern: adding behaviour to an object by wrapping it in others with the same interface, and how it differs from Python's @ syntax.
Intermediate to Advanced8 cards · 5 qnot started
- Design Patterns
The Facade pattern: one simple interface in front of a complex subsystem, with the subsystem's classes still there for the cases the facade does not cover.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
The Composite pattern: treating a single object and a group of objects the same way, as in files and folders.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
The Bridge pattern: splitting what something is from how it is done into two hierarchies, so they grow without multiplying classes.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
The Flyweight pattern: sharing the common part of many small objects so that a program holding millions of them still fits in memory.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
The State pattern: giving each state of an object its own class, so behaviour changes when the state changes, and deciding which class chooses the next state.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
The Chain of Responsibility pattern: passing a request along a chain of handlers until one deals with it, and ending every chain with an answer for requests nobody accepts.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
The Mediator pattern: routing the communication between many objects through one coordinator, and counting the links it removes.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
The Memento pattern: saving an object's state as a snapshot only that object can read, so it can be restored later, and keeping the snapshots from filling the memory.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
The Interpreter pattern: representing each rule of a small language as a class, evaluating a sentence as a tree of those objects, and knowing that parsing is a separate job.
Intermediate to Advanced8 cards · 4 qnot started
- Design Patterns
Choosing a creational design pattern: telling Factory Method, Abstract Factory, Builder, Prototype and Singleton apart, and when a plain constructor is enough.
Intermediate to Advanced5 cards · 4 qnot started
- Design Patterns
Choosing a structural design pattern: telling Adapter, Decorator, Facade, Proxy, Composite, Bridge and Flyweight apart by what each wrapper is for.
Intermediate to Advanced5 cards · 4 qnot started
- Design Patterns
Choosing a behavioural design pattern: telling Strategy, State, Template Method, Command, Observer, Mediator, Chain of Responsibility and Decorator apart by who decides and how many objects take part.
Intermediate to Advanced5 cards · 5 qnot started
- Java Collections and Streams
The Java Collections Framework: List, Set and Queue, what each promises, and which type to declare a variable with.
Intermediate to Advanced8 cards · 5 qnot started
- Java Collections and Streams
Java Optional: a return type that puts possible absence in the signature, how to unwrap it, and where it does not belong.
Intermediate to Advanced8 cards · 5 qnot started
- Java
Java polymorphism: how the runtime object chooses which overridden method runs, what the declared type decides, hiding, casts and instanceof.
Intermediate to Advanced9 cards · 5 qnot started
- Java
Java interfaces and abstract classes: naming a capability, sharing state, default methods, and choosing between the two.
Intermediate to Advanced8 cards · 5 qnot started
- Java Collections and Streams
Sorting your own types in Java: Comparable for the natural order, Comparator for the rest, and the two ways a comparator goes wrong.
Intermediate to Advanced9 cards · 5 qnot started