SOLID, S:단일 책임 원칙 (SRP)

객체지향 설계 원칙(SOLID)은 앞서 작성한 객체지향 이해하기를 보고오는게 좋다

왜냐하면 캡슐화, 상속, 다형성, 추상화를 어떻게 쓸것인가? 에 대한 고민으로
엉클 밥님이 만든걸 멋지게(?) 앞자리만 따서 만든게 SOLID기 때문이야

핵심은 유지보수 할 때를 고려해서, 변경에 유연하고 가독성 좋게 짜는거야

S. 단일 책임 원칙 (Single Responsibility Principle)

클래스는 하나의 이유로만 변경돼야 한다!

 

문제 상황

1~2년 차쯤 개발할 때, 하나의 클래스에 너무 많은 기능을 몰아넣었던 기억이 있어.
예를 들어 MemberService 하나에 아래 기능들을 다 넣는다고 해보자.

• 회원 가입
• 로그인
• 비밀번호 찾기
• 이메일 인증
• 알림 발신

여기에 공통적으로 사용하는 사용자 조회 기능이 있다고 가정해보자.

근데 이제 알림 발신을 카카오톡으로 가입한 사용자에겐 카카오톡으로만 알림을 보내도록 수정한다고 하면?

 

문제는 그 사용자 조회 로직이 MemberService에 그대로 얽혀 있으면 발생하는거지

• 로그인, 가입, 비밀번호 찾기 같은 기능도 다 영향을 받아
• 기능 하나만 수정하려 해도 전반적인 테스트 필요하고
• 작은 실수로 로그인이 아예 안 되는 치명적인 장애 발생(카카오톡 가입자만 로그인 가능 등) 할 수 있어

물론 작업자가 모든 기능을 외우고 있다면 문제가 발생하지 않을 수 있지

하지만 대부분은 다 외울 수 없을거야

나는 기능을 추가하면서 유지보수를 떠올리고

작업의 크기보다 책임의 크기가 큰 상황은 분명 부정적인 상태라고 판단해

당연히 확인해야할 것들이 많아지고 개발 시간도 늘어날 수 밖에 없어

그래서 책임을 분리해야해

 

책임 분리

각 기능을 다음처럼 나눠보자

• MemberRegisterService
• MemberLoginService
• MemberPasswordFindService
• EmailVerificationService
• AlertService

이렇게 기능별로 책임을 분리하면,

• 변경 시 영향 범위가 작아지고
• 장애 가능성도 줄어들고
• 테스트도 단위별로 훨씬 수월해져

 

이게 책임의 분리이고 응집도가 높고 결합도가 낮은 서비스 설계라고 할 수 있지

단일 책임 원칙이 말하는 핵심이야

"클래스를 나누자!" 라고 생각하는게 아니야, "변경에 유연하고 가독성 좋게" 

하나의 클래스는 하나의 변경 이유만 가지도록 설계한다!