SOLID 원칙 (2) - 단일 책임 원칙(SRP)

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

• 클래스는 하나의 책임만 가진다.
• 클래스가 제공하는 모든 서비스(methods)는 그 책임을 수행하는데 집중한다.
• 환경이 바뀌어 클래스를 변경하는 경우는 오직 하나 뿐이어야 한다.
• 환경 변화로 하나의 클래스가 여러 책임을 갖는 경우 → 클래스 분할
• 복잡한 프로세스를 구현하거나 경험이 부족하면 지키기 어렵다.
• 대부분 SW 위협 원인이 된다.

SRP 장점

• 클래스 책임 영역이 확실하다 → 하나의 책임 변경에 따른 연쇄 변경에서 자유롭다.
• 응집도 강화, 결합도 약화, 가독성 향상, 유지보수 용이.

SRP 준수 전략

• 중복된 책임은 추상 클래스로 구현.
• 기존의 클래스로 해결할 수 없다면 새로운 클래스 구현.

응집도 강화 및 결합도 약화 예시

응집도 강화 예시: Invoice 클래스가 있고 이 클래스는 청구서 관련 데이터를 관리하며, 청구서의 PDF 생성, 청구서의 이메일 발송 기능을 가지고 있을 때, PDF 생성과 이메일 발송 기능을 별도의 클래스로 분리하여 InvoicePDFGenerator와 InvoiceEmailSender 클래스를 만들면, 각 클래스는 각각 PDF 생성과 이메일 발송이라는 하나의 책임만을 가지게 되어 응집도가 강화된다.

결합도 약화 예시: ReportGenerator 클래스가 데이터베이스에서 데이터를 조회하여 보고서를 생성하는 기능을 가지고 있다고 할 때, 이 클래스가 특정 데이터베이스 기술에 직접 의존한다면, 데이터베이스 기술이 변경될 때마다 ReportGenerator 클래스도 변경해야 한다. 이를 방지하기 위해, 데이터베이스 접근을 담당하는 별도의 인터페이스(예: DatabaseAccess)를 정의하고, ReportGenerator는 이 인터페이스에만 의존하게 하여 결합도를 약화시킬 수 있다.

- 단일 책임 원칙 위배 예시

Order	▶ 환경 변화	Order
+ List items + List quantities + List price + String status = 'open'		+ List items + List quantities + List price + String status = 'open'
+ add_items(name, quantities, price) + total_price()		+ add_items(name, quantities, price) + total_price() + pay(payment_type, security_code)
주문 기능 전체 주문 가격 확인 기능		주문 상품에 대한 금액 지급 추가

 

Order 클래스에 관련 없는 책임(pay)를 추가로 갖게 되었으니, pay() 기능만 책임을 지는 클래스를 구현하여 책임을 분리