SoC

Separation of Concerns

“The art of separation of concerns is likely the most single important concept in software engineering.”

Distinct sections of the computer program should address distinct issues.

When to use

Architecturally. When defining layers (UI, Logic, Data). When designing classes.

Why it matters

  • Organization: You know where to look for things. UI stuff is in the UI folder. SQL stuff is in the DB folder.
  • Parallel Development: The frontend team can work on the UI while the backend team works on the API.

Signs of Violation

  • HTML strings inside SQL queries.
  • SQL queries inside HTML templates.
  • Business logic inside Controller actions.

Explanation

Problem

If concerns are mixed (e.g., calculation logic inside the UI button click handler), you can’t test the logic without clicking the button. You can’t change the UI without potentially breaking the logic.

Solution

Divide the system into distinct features with as little overlap in functionality as possible.

Real world analogy

House construction. The plumber handles water. The electrician handles power. The framer handles structure. They don’t mix jobs (you don’t run water through electrical conduits).

Pros and Cons

Pros Cons
  • Modularity
  • Testability
    		•
  • Can lead to “Over-abstraction” if separated too granularly
    		•

    Comparison

    • SRP: SoC is higher level (architectural), while SRP is class level.
    • Layered Architecture: A common way to implement SoC.

    Code example

    Typescript

    Bad (Violation)

    Good (Adherence)

    PHP

    Bad (Violation)

    Good (Adherence)