Separate concerns

Split code by responsibility, so unrelated concerns don’t mix. It’s a form of modularization but applies to both logic and organization. This principle requires a solid understanding of what constitutes a 'concern.' Traditionally, this was confused with 'separation of technologies' where CSS, HTML, and JS were meant to be separated. Rather things which change together should be as close to each other as reasonably possible. This reduces indirection (in some cases it can be completely eliminated) which makes evolving the codebase easier.

Examples

  • In a React application when building a date picker component, you are careful to avoid letting use-case specific concepts (like loading available dates from a database) slip into the implementation of the date picker and instead require those to be loaded and configured by the calling developer.