📖 [7장] SRP: 단일 책임 원칙
📘 클린 아키텍처 북스터디 정리입니다
📚 도서: 로버트 C. 마틴 《Clean Architecture》
🧑💻 목적: 올바른 설계에 대한 감각과 습관을 익히기 위해
🗓️ 진행 기간: 2025년 7월 ~ 매주 2장
✅ 핵심 요약 (Key Takeaways)
이 장의 핵심 문장은?
단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다
저자가 전달하고자 하는 메세지 요약
- 소스 코드는 책임에 따라 분리되어야 한다.
- 각 단위는 하나의 책임과 유효 범위를 가져야 한다.
- 유효 범위 밖에서는 그 내부의 멤버에 대해 알 수도, 접근할 수도 없어야 한다.
💡 내용 정리
서론 - 단일 책임 원칙(SRP)
- 단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다
변경의 이유: 액터(사용자와 이해관계자)
모듈: 소스 파일 또는 함수와 데이터 구조로 구성된 응집된 집합
응집성: 단일 액터를 책임지는 코드를 함께 묶어주는 힘
SRP 위반의 징후
- 많은 사람들이 서로 다른 목적으로(변경의 이유) 동일한 소스파일(모듈)을 변경하는 경우
1. 우발적 중복
- 여러 액터가 서로 다른 목적으로 같은 클래스의 메서드를 변경하는 경우
- 예시:
Employee클래스에calculatePay,reportHours,save등 액터가 다른 메서드들이 공존
2. 병합
- 서로 다른 책임이 한 클래스에 합쳐져, 작은 변경이 다른 기능에 영향을 줌
해결책
데이터와 메서드 분리
클래스는 하나의 책임(유효 범위)만을 가져야 함
- 유효 범위 외부에서는 내부의 멤버에 대해 알 수 없음
Good case
// 책임이 올바로 나눠진 예시
public class InvoicePrinter {
public void print(Invoice invoice) { ... } // 인쇄 역할
}
public class InvoicePersistence {
public void save(Invoice invoice) { ... } // 저장 역할
}Bad case
public class InvoiceManager {
public void print(Invoice invoice) { ... }
public void save(Invoice invoice) { ... }
public void email(Invoice invoice) { ... }
}
결론
- 단일 책임 원칙: 메서드와 클래스 수준의 원칙
- 공통 폐쇄 원칙: 컴포넌트 수준의 원칙
- 아키텍처 경계의 생성을 책임지는 변경의 축: 아키텍처 수준
용어
파사드 패턴
- 복잡한 시스템을 단순화하여 감추고 외부에는 단순한 인터페이스를 제공하는 패턴
파사드 패턴의 구성 요소
- 파사드: 복잡한 서브 시스템의 기능을 통합해 단순한 인터페이스로 외부에 제공
- 서브시스템: 설계 비즈니스 로직, 복잡한 처리들을 담당하는 내부 컴포넌트들
- 클라이언트: 파사드가 제공하는 단순화된 인터페이스만을 사용하는 외부 코드
[Client] → [Facade] → [SubsystemA]
↘︎ [SubsystemB]
↘︎ [SubsystemC]💡 인상 깊었던 문장 & 나의 인사이트
책에서 가장 기억에 남는 문장
SRP는 서로 다른 액터가 의존하는 코드를 서로 분리하라고 말한다
인상 깊었던 문장과 관련된 인사이트
단일 책임 원칙.
많이 들어본 용어이다.
코드를 책임에 따라 분리하라는 말은 많이 들어봤지만,
그 ‘책임’이란 것이 무엇인지는 사실 잘 와닿지 않았다.
책에서는 그 책임을 ‘액터(사용자와 이해관계자)’의 의존으로 설명했다.
결국 코드를 분리하는 기준은 단순히 기능이나 역할이 아니라,
누가 이 코드에 영향을 미치고, 변경을 요구하는가에 있다는 사실이 인상 깊었다.
앞으로는 코드를 작성하기 전에
먼저 사용자와 이해관계자가 누구인지 정의하고,
그들의 의존에 따라 책임을 나누는 연습을 해야겠다고 느꼈다.
🛠 실무 적용 아이디어 (To Action)
✅ 오늘부터 실천할 작은 실천
- 각각의 액터들 구분한 후 액터의 의존에 따라 코드 분리
