SOLID Principles
Five design principles for writing maintainable object-oriented code.
The five SOLID principles of object-oriented design with a description and an example each, followed by related design principles: DRY, KISS, YAGNI, the Law of Demeter, composition over inheritance, separation of concerns and Tell, Don't Ask.
Use it when
- You need the principle behind a design decision or a code-review comment.
- You are teaching object-oriented design.
Watch out for
- Principles are guidelines that conflict at times; DRY can push toward abstractions that YAGNI warns against.
- Taken to extremes, they produce over-engineered code.
The data
12 rows
| Principle | Description | Example |
|---|---|---|
| S - Single Responsibility | A class should have only one reason to change. | Separate UserAuth from UserProfile. |
| O - Open/Closed | Open for extension, closed for modification. | Add new payment types without changing existing processor. |
| L - Liskov Substitution | Subtypes must be substitutable for their base types. | A Square should not extend Rectangle if width=height invariant breaks. |
| I - Interface Segregation | Prefer many small client-specific interfaces over one large interface. | Separate Printer and Scanner interfaces. |
| D - Dependency Inversion | Depend on abstractions, not concrete implementations. | Controller depends on ILogger interface, not FileLogger. |
| DRY - Don't Repeat Yourself | Every piece of knowledge should have a single, authoritative representation. | Define a validation rule once and reuse it instead of copying it into several handlers. |
| KISS - Keep It Simple | Prefer the simplest design that solves the problem. | Use a plain function before introducing a class hierarchy. |
| YAGNI - You Aren't Gonna Need It | Do not add functionality until it is actually needed. | Skip a plugin system until a second implementation exists. |
| Law of Demeter | A unit should talk only to its immediate collaborators, not reach through them. | Call order.total() instead of order.getCustomer().getAccount().getBalance(). |
| Composition over Inheritance | Combine small objects to get behavior instead of extending class hierarchies. | Give a Car an Engine object rather than making Car a subclass of Engine. |
| Separation of Concerns | Divide a program into parts that each address a distinct concern. | Keep data access, business rules and presentation in separate layers. |
| Tell, Don't Ask | Tell objects what to do instead of asking for their state and acting on it. | Call account.withdraw(amount) rather than reading the balance and deciding outside. |
Fields
The shape of this dataset, read from the data itself: every column, its type and a real value. Agents can use this to plan a query without fetching the whole document.
| Section | Field | Type | Example |
|---|---|---|---|
| data | principle | string | S - Single Responsibility |
| data | description | string | A class should have only one reason to change. |
| data | example | string | Separate UserAuth from UserProfile. |
Fetch the same bytes
The static files contain the same reference rows as the API, with no API rate limit. Live metadata, such as view counts, may differ. Use the API for content negotiation; use the static files for a cacheable snapshot.
curl "https://yjtoon.yunusemrevurgun.com/api/dataset/solid-principles?format=toon"
const res = await fetch( "https://yjtoon.yunusemrevurgun.com/static-data/dataset/solid-principles.toon" ); const toon = await res.text();
Rate limit: 120 requests per minute per IP, no key and no signup. API reference →