Separation of concerns is similar to the [[Principle of Atomicity]] in that it also involves the distillation of complex code down to self-contained modules. However, the concept of separation of concerns involves not just atomicity in functionality, but also in purpose and [[Respect Levels of Abstraction|level of abstraction]]. The main benefit of a separation of concerns in programming is the code's ease of maintenance, whether it's by the original programmer or not. It's significantly easier to troubleshoot errors when the cause can be pinpointed to something within a small function. ## Separation of Concerns in practical terms ### Separation of Functions Write helper functions, not [[Spaghetti Code]]. ### Separation of Things In [[Object-oriented programming]] languages, create a separate object for each thing instead of having [[God Objects]] ### Separation of Modules Use a file structure for your code that distinguishes between different concerns. Not doing this increases the chances of creating a [[Monolith]]. For applications with a GUI, code can be separated into three different levels: - The UI - Logic - Data Writing a function that addresses more than one of these breaks the separation of concerns and adds to troubleshooting time. ### [[Command-Query Separation]] ### [[Respect Levels of Abstraction|Respecting levels of abstraction]] ## References - [[Programming Fundamentals Part 5: Separation of Concerns]] - [[Respecting Levels of Abstraction - Simple Programmer]]