단일 책임 원칙(Single Responsibility Principle, SRP)

SRP는 SOLID 원칙 중 첫 번째 원칙으로, 한 개의 모듈은 오직 한 개의 액터에만 책임을 가져야 한다는 원칙이다. 

A module should be responsible to one, and only one, actor.

(Actor : 모듈의 변경을 요구하는 하나 이상의 이해관계자나 사용자 그룹)

SRP에서 책임의 의미 

일반적인 객체지향 설계에서의 책임(역할, 책임, 협력에서의 책임)

• 객체가 수행해야 하는 행동(behavior)을 의미
• 객체가 "무엇을 알고"(knowing) "무엇을 하는지"(doing)를 나타냄
• 협력 관계 속에서 객체가 수행해야 하는 역할을 의미
• 주로 메서드나 기능 단위의 책임을 의미

SRP에서의 책임

• 변경의 이유(reason for change)를 의미
• 특정 액터(이해관계자)의 요구사항을 의미
• 하나의 모듈이 변경되어야 하는 이유는 오직 하나여야 함
• 더 큰 단위의 책임을 다룸

	범위	적용 수준	목적	결과
일반적 책임	객체의 행동과 상태에 초점	메서드나 기능 단위의 미시적 책임	객체의 역할과 협력 관계 정의	잘 정의된 객체의 행동
SRP에서의 책임	변경의 원인과 이해관계자에 초점	클래스나 모듈 단위의 거시적 책임	변경의 영향 범위 제어와 관리	독립적으로 변경 가능한 모듈

 

 

 

SRP에서 중요한 점

1. "책임"은 "변경의 이유"를 의미한다.
2. 하나의 클래스는 하나의 액터(이해관계자)에 대해서만 책임을 져야 한다.
3. 서로 다른 이유로 변경되는 것들은 분리되어야 한다.

변경할 이유를 무엇으로 정의하는가? 

• 버그 수정이나 리팩토링에 관한 것이 아님(프로그래머의 책임)
• 프로그램의 책임과 누구에게 응답하는지에 초점

예시 코드 1

조직 구조

• 최상위에 CEO
• CEO에게 보고하는 C레벨 임원(Employee)
  • CFO (재무 담당)
  • CTO (기술 담당)
  • COO (운영 담당) 

시나리오 1) 급여 계산 규칙을 잘못 명세하여 모든 직원들이 두 배의 급여를 받음

calculatePay 메서드가 치명적으로 잘못 명세된 것이므로 이 책임은 CFO가 져야한다.

 

시나리오 2) 저장하는 과정에 기업 데이터가 손상

save 메서드의 치명적인 잘못된 명세가 있는 기술적인 문제로 이 책임은 CTO가 져야 한다.

 

시나리오 3) 직원들의 근무 현황 및 보상을 추적하는 리포트에 오류가 있는 경우

reportHours 메서드에 잘못된 명세가 존재하는 운영상의 책임으로 이 책임은 COO가 져야 한다.

// SRP 위반
public class Employee {
    public Money calculatePay(); // CFO 조직의 책임 (급여 계산 로직)
    public void save(); // CTO 조직의 책임 (데이터 저장 기술)
    public String reportHours(); // COO 조직의 책임 (운영/감사 보고)
}

위 코드는 하나의 클래스 내에 서로 다른 조직의 책임들이 섞여 있다. 

 

calculatePay 메서드 내의 알고리즘에 변경이 이루어질 때, 그 변경 요청은 CFO가 이끄는 조직에서 발생할 것이다.

마찬가지로 reportHours 메서드에 대한 변경은 COO의 조직에서 요청할 것이고, save 메서드에 대한 변경은 CTO의 조직에서 요청할 것이다. 

 

현재 해당 클래스에는 서로 다른 액터(CFO, CTO, COO 조직)에 응답하는 3개의 메서드가 있다. (SRP 위반)

위의 코드처럼 한 클래스 내에 3개의 다른 그룹의 비지니스 기능이 있게 될 경우, CTO가 요청한 변경이 의도치 않게 COO가 책임을 져야 되는 상황이 발생할 수 있다. (calculatePay 메서드의 변경이 의도치 않게 reportHours 메서드를 망가뜨린 상황)

 

따라서, 소프트웨어 모듈을 작성할 때, 변경이 요청될 때 그 변경은 단일하고 좁게 정의된 비즈니스 기능을 대표하는 밀접하게 결합된 그룹으로부터만 발생할 수 있도록 하는 것이 이상적이다. 즉, 모듈들을 조직 전체의 복잡성으로부터 격리시키고, 각 모듈이 하나의 비즈니스 기능의 필요에만 책임을 지도록 시스템을 설계해야 한다.

 

SRP를 준수하려면 다음 코드와 같이 분리되어야 한다. (한 클래스가 한 엑터에 대한 책임(변경의 이유)만 가지도록)

// SRP 준수
// CFO 조직의 책임
public class EmployeePayCalculator {
    public Money calculatePay(); // CFO 조직의 책임 (급여 계산 로직)
}

// CTO 조직의 책임
public class EmployeeRepository {
    public void save(); // CTO 조직의 책임 (데이터 저장 기술)
}

// COO 조직의 책임
public class EmployeeTimeReporter {
    public String reportHours(); // COO 조직의 책임 (운영/감사 보고)
}

위처럼 각 클래스가 하나의 변경의 이유(책임)만 가지도록 설계하면 다음과 같은 이점이 있다.

• 각 클래스는 하나의 조직에서만 변경 요청이 발생
• 한 기능의 변경이 다른 기능에 영향을 주지 않음(책임 혼합 피함)
• 각 조직의 요구사항 변경을 독립적으로 반영 가능

따라서 SRP 준수하면 "급여 계산 로직을 수정했는데 근무시간 보고서에 결함이 발생하는" 상황을 예방할 수 있다.

 

예시 코드 2

리포트 모듈 사례

• 변경 이유 1: 리포트 내용 변경
• 변경 이유 2: 리포트 형식 변경
• 서로 다른 이유로 변경되므로 별도 모듈로 분리해야 함

// SRP 위반
class Report {
    private String content;
    private String format;

    public Report(String content, String format) {
        this.content = content;
        this.format = format;
    }

    // 리포트 데이터 생성 책임
    public void generateReport() {
        // 데이터베이스에서 데이터를 가져오는 로직
        System.out.println("리포트 내용 생성 중...");
        this.content = "리포트 데이터...";
    }

    // 리포트 포맷팅 책임
    public void formatReport() {
        // 포맷팅 로직
        System.out.println("리포트 포맷팅 중...");
    }

    // 리포트 출력 책임
    public void printReport() {
        // 출력 로직
        System.out.println("리포트 출력 중...");
    }
}

 

SRP 위반

• Report 클래스가 여러 책임을 가지고 있다.
  • 리포트 데이터 생성(generateReport())
  • 리포트 포맷팅(formatReport())
  • 리포트 출력(printReport())
• 발생가능한 문제
  
  • 데이터 생성 방식이 변경되면 클래스 전체(Report 클래스)에 영향
  • 포맷팅 요구사항 변경 시 (Report 클래스) 수정 필요
  • 출력 방식 변경 시에도 (Report 클래스) 수정 필요

// SRP 준수
// 1. 리포트 데이터 생성 책임
class ReportGenerator {
    private String content;

    public String generateReport() {
        // 데이터베이스에서 데이터를 가져오는 로직
        System.out.println("리포트 내용 생성 중...");
        return "리포트 데이터...";
    }
}

// 2. 리포트 포맷팅 책임
class ReportFormatter {
    public String formatReport(String content, String format) {
        // 포맷팅 로직
        System.out.println("리포트 포맷팅 중...");
        return "포맷팅된 " + content;
    }
}

// 3. 리포트 출력 책임
class ReportPrinter {
    public void printReport(String formattedReport) {
        // 출력 로직
        System.out.println("리포트 출력: " + formattedReport);
    }
}

 

SRP 준수

• 각 책임이 별도의 클래스로 분리되어 있다.
  • ReportGenerator: 데이터 생성만 담당
  • ReportFormatter: 포맷팅만 담당
  • ReportPrinter: 출력만 담당
• 장점
  • 한 부분의 변경이 다른 부분에 영향을 미칠 위험 감소
    • ex : 리포트 컴파일 프로세스 변경이 출력 코드에 영향을 주지 않음
  • 변경이 필요할 때 관련 클래스만 수정(유지보수성 향상)
    • 각 컴포넌트를 독립적으로 수정 가능
    • 버그 발생 시 원인 파악 쉬움
  • 테스트 용이성
    • 각 책임을 독립적으로 테스트 가능
    • Mock 객체 사용 용이

단일 책임 원칙 다른 표현 방식 

Gather together the things that change for the same reasons. Separate those things that change for different reasons. (Robert C. Martin, 2014)

같은 이유로 변경되는 것들을 함께 모으고(응집도↑), 다른 이유로 변경되는 것들은 분리하자.(결합도↓).

 

 

SRP는 사람에 관한 것

마지막으로, 변경의 이유는 사람이라는 것을 생각하자. 변경을 요청하는 것은 사람들이다.

우리는 서로 다른 이유로 사람들이 관심을 가지는 코드를 혼합을 피해야 한다.

• 변경은 한 사람/그룹에서만 발생해야 함
• 각 모듈은 하나의 비즈니스 기능에만 응답해야 함
• 조직의 복잡성으로부터 격리되어야 함

 

 

참고 자료 :

https://en.wikipedia.org/wiki/Single-responsibility_principle

Single-responsibility principle - Wikipedia

 

https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

Clean Coder Blog