C#

C# 기초부터 고급까지 Chapter 2.1.1. SRP (Single Responsibility Principle) – 단일 책임 원칙

Juan_ 2025. 4. 27. 20:57
728x90

📚 Chapter 2.1.1: SRP (Single Responsibility Principle) – 단일 책임 원칙

✅ SRP란?

"하나의 클래스(또는 모듈)는 하나의 책임만 가져야 한다."
👉 변경 이유(Reason to change)가 단 하나여야 한다는 거다!

🔥 쉽게 풀자

  • "A 클래스는 ~도 하고 ~도 하고 ~도 한다" → ❌
  • "A 클래스는 단 하나의 일만!" → ⭕ (깔끔하고 유지보수 쉽다)

📚 왜 SRP가 중요한가?

문제 상황 결과
여러 책임을 가지면 한 책임 변경 시, 다른 책임도 영향을 받음
클래스 크기 폭발 읽기, 수정, 테스트가 어려워짐
코드 중복, 버그 증가 한 번에 여러 기능이 꼬임

✅ 단일 책임 원칙을 지키면 →

  • 수정 시 영향 최소화
  • 테스트 쉽고 빠름
  • 코드 읽기가 쉬움

🛠️ 기본 예제: 나쁜 설계

public class ReportManager
{
    public string Title;
    public string Content;

    public void SaveToDatabase()
    {
        Console.WriteLine("DB에 저장");
    }

    public void GeneratePDF()
    {
        Console.WriteLine("PDF 파일 생성");
    }
}

❌ 문제점

  • ReportManager가 "문서 관리"도 하고,
  • "DB 저장"도 하고,
  • "PDF 생성"도 하고 있다.

👉 책임이 세 개나 있음! (문서 관리, DB 저장, PDF 출력)

🛠️ SRP 적용: 좋은 설계

public class Report
{
    public string Title;
    public string Content;
}

public class ReportDatabaseSaver
{
    public void Save(Report report)
    {
        Console.WriteLine("DB에 저장");
    }
}

public class ReportPrinter
{
    public void PrintToPDF(Report report)
    {
        Console.WriteLine("PDF 파일 생성");
    }
}

✅ 개선 포인트

  • Report: 문서 내용 관리만
  • ReportDatabaseSaver: DB 저장만
  • ReportPrinter: PDF 출력만

→ 책임이 딱딱 분리되었다!!

📚 실무 버전 예시: 서비스 레이어에서

public class UserService
{
    private readonly UserRepository _userRepository;
    private readonly EmailService _emailService;

    public UserService(UserRepository userRepository, EmailService emailService)
    {
        _userRepository = userRepository;
        _emailService = emailService;
    }

    public void RegisterUser(string email, string password)
    {
        _userRepository.Save(email, password);
        _emailService.SendWelcomeEmail(email);
    }
}

✅ UserService는 "회원가입 로직"만 한다.

  • 저장은 UserRepository가,
  • 이메일 발송은 EmailService가 책임진다.

→ SRP 덕분에 각 기능이 단독으로 수정/확장 가능하다!

✨ SRP 심화 – 진짜 잘하는 실무 포인트

팁 설명
"And" 냄새 맡아라 클래스 이름에 "And" 들어가면 SRP 위반 의심!
메서드 수 10개 넘으면 "책임 분리" 고려하라
데이터 모델 vs 동작 가능하면 모델과 동작 분리 (DTO, Service 등)
테스트 작성할 때 힘들면 책임 분리 신호다

🎯 SRP를 지키면 생기는 실무 장점

항목 효과
변경 영향 최소화 수정해도 다른 기능 터지지 않음
기능 추가 쉬움 새 클래스 만들어 붙이면 끝
코드 리뷰 빨라짐 명확한 책임 구조
테스트 코드 작성 쉬움 독립 테스트 가능

✅ SRP 요약

항목 설명
목표 클래스는 하나의 책임만 가져라
수정 이유 오직 하나만 있어야 한다
신호 클래스가 비대해지고, 기능이 뒤섞이면 분리하자
728x90