Separation of Concerns (SoC)

Imagine you are building an online shopping system.

A junior developer writes:

class OrderManager
{
public:

    void placeOrder()
    {
        // Read input from UI

        // Validate user

        // Calculate taxes

        // Calculate discounts

        // Save to database

        // Send email

        // Generate invoice

        // Log activity

        // Update analytics

        // Handle errors
    }
};

Everything work.

Until requirements change.

Now:

Tax logic changes

You modify:

placeOrder()

Then:

Email provider changes.

Again:

placeOrder()

Eventually:

3000-line function

This happens because multiple concerns became mixed together.

To solve this problem, software engineering developed:

Separation of Concerns (SoC).

Historical Background

One of the earliest and most influential ideas in software engineering came from: Edsger W. Dijkstra

Dijkstra observed:

The effectiveness of a programmer is largely determined by the ability to separate concerns.

As systems became larger:

Thousands of Files
Millions of Lines of Code
Hundreds of Developers

Software became impossible to maintain when everything was connected to everything else.

The solution:

Divide responsibilities into isolated concerns

This became Separation of Concerns.

What Is a Concern?

A concern is:

A specific responsibility or area of interest within a system.

Examples:

Authentication
Authorization
Persistence
Logging
Validation
Reporting
Notifications
Busines Rules
Caching
Error Handling

Each represents:

A Different Concern

Core Principle

The principle is simple:

Each part of the system should focus on one concern and avoid mixing unrelated concerns.

Bad:

UI
+
Datbase
+
Business Logic
+
Logging

inside one class.

Good:

UI Layer
Business Layer
Persistence Layer
Infrastructure Layer

Each concern has a clear owner.

Real-World Analogy

Consider a hospital.

Doctors:

Treat Patients

Receptionists:

Manage Appointments

Accountants:

Handle Billing

Security:

Control Access

Each role focuses on a separate concern.

Imagine if one person did everything.

Chaos.

Software behaves the same way.

Tangled Code

One of the biggest symptoms of poor SoC.

Example:

void registerUser()
{
    // Display UI

    // Validate email

    // Save to database

    // Send email

    // Write logs

    // Generate report

    // Update analytics
}

Question:

What is this function responsible for?

Answer:

Everything

That means:

Nothing Clearly

This is tangled code.

Separating the Concerns

Instead:

class UserValidator
{
};

class UserRepository
{
};

class EmailService
{
};

class AuditLogger
{
};

class UserRegistrationService
{
};

Now responsibilities are clear.

Each conern evolves independently.

Relationship with SRP

Many developers confuse:

SRP

and

SoC

They are related by different.

SRP:

Class-Level Principle

SoC:

System-Level Principle

SRP asks:

Should this class have one responsibility?

SoC asks:

Should these concerns be separated?

Think:

SRP = Local
SoC = Global