SOLID 원칙 이해하기: SRP(단일 책임 원칙)
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
개발 툴
대상자
- 중급 이상 개발자
- 코드 품질 개선을 목표로 하는 프로그래머
- 객체지향 설계 패턴에 관심 있는 개발자
- Golang/elixir 프레임워크 사용자
핵심 요약
- SRP(단일 책임 원칙) 정의
클래스 또는 모듈은 하나의 변경 이유만 가져야 한다.
(Clean Code, p.138)- SRP 위반 예시
User
구조체에SaveUser()
메서드 추가 (Go 예제)- Elixir의
User
모듈에서 사용자 생성, 이메일 전송, 로깅이 하나의 함수에 포함 - SRP 준수 실천 방법
UserCreator
,WelcomeNotifier
모듈로 책임 분리 (Elixir 예제)- 데이터 처리와 비즈니스 로직 분리
섹션별 세부 요약
1. 서론
- SOLID 원칙은 20년 이상 적용되는 설계 원칙
- SRP는 코드 품질 향상에 핵심적인 역할
- 예제 코드는 Elixir 및 Golang으로 제공
2. SRP의 정의 및 중요성
- Robert Martin의 _Design Principles and Design Patterns_에서 도입
- 1980년대 이후 응용 프로그램 복잡도 증가로 SRP 필요성 발생
Clean Code
에서 SRP 정의:클래스 또는 모듈은 하나의 변경 이유만 가져야 한다.
3. SRP 위반 사례 (Go 예제)
User
구조체에SaveUser()
메서드 추가- 데이터 저장은 도메인 책임이 아닌 인프라 책임
func (u *User) SaveUser()
→ SRP 위반
4. SRP 위반 사례 (Elixir 예제)
User
모듈에서 사용자 생성, 이메일 전송, 로깅이 하나의 함수에 포함def create_user(attrs)
→ SRP 위반- 수정된 코드:
UserCreator
모듈로 사용자 생성WelcomeNotifier
모듈로 이메일 전송Logger
모듈로 로깅 분리
5. 실무 적용 팁
- 각 컴포넌트의 변경 이유를 명확히 정의
- 데이터 처리 및 비즈니스 로직 분리
- 예제 코드는 Elixir 및 Golang 레포지토리에서 확인 가능
결론
- SRP 준수를 위해 책임 분리를 반드시 실천
User
구조체에 저장 로직 포함은 SRP 위반 (Go 예제)- Elixir의
create_user()
함수는 사용자 생성, 이메일 전송, 로깅 분리 필요 - 실무에서 각 모듈의 책임을 명확히 정의하여 코드 품질 향상
- 예제 코드는 Elixir 및 Golang 레포지토리에서 확인 가능