separation-of-concerns
Separation of Concerns
Overview
Each piece of code should do one thing. Data, logic, and presentation should be separate.
Mixed concerns create untestable, unreusable, unmaintainable code. Separation enables testing, reuse, and clarity.
When to Use
- Component fetches, transforms, and displays data
- Business logic mixed with UI code
- Database queries in controllers
- Hard to test a piece of code in isolation
The Iron Rule
NEVER mix data fetching, business logic, and presentation in one place.
More from yanko-belov/code-craft
dont-repeat-yourself
Use when writing similar code in multiple places. Use when copy-pasting code. Use when making the same change in multiple locations.
84lazy-loading
Use when loading all data upfront. Use when initial page load is slow. Use when fetching data that might not be needed.
54keep-it-simple
Use when tempted to write clever code. Use when solution feels complex. Use when showing off skills instead of solving problems.
51single-responsibility-principle
Use when creating or modifying classes, modules, or functions. Use when feeling pressure to add functionality to existing code. Use when class has multiple reasons to change.
39fail-fast
Use when handling errors. Use when tempted to catch and swallow exceptions. Use when returning default values to hide failures.
35race-conditions
Use when multiple operations access shared state. Use when order of operations matters. Use when "it works most of the time" but occasionally fails mysteriously.
34