Single Responsibility Principle 이해하기

Seonghoon Kim·2021년 9월 26일

목록 보기

1/1

SOLID principle의 첫 원칙인 SRP에 대해 모호했던 부분들이 있었고, 다시 이해하고 헷갈리고를 반복하는 과정이 있었기때문에 간략히 정리해본다.

SRP가 정리된 글들을 종종 읽어보면, 너무 생략해서

한 기능은 한 역할만 해야한다.

라고 설명한다.

그렇다면 질문이 추가로 생기게된다.

하나의 기능은 무엇이고 하나의 역할은 무엇일까?
이 질문에 대한 해답을 찾기 전에 SOLID가 무엇을 위함인지를 아는 것이 먼저이다.

SOLID는 완벽하지도 않고 휴리스틱을 이용하여 해결을 위한 가이드이다. [1]

SOLID는 5개의 design principles들을 이용해서 유지보수를 쉽게 도와주고, 기능을 쉽게 이해하도록 도와주고, 개발확장성 쉽게하도록 도와준다. [2]

간략하게 이 정도면 SOLID가 무엇을 추구하는지는 알게되었다.

다시 원래의 질문으로 돌아와 답변해보자

하나의 기능은 무엇일까?

모듈이다. [3]
하지만 모듈이라는 것은 너무 모호해서 단순히 함수와 데이터 정보를 묶은 Class정도로 이해해도 괜찮다.

그렇다면 첫 질문인 기능의 단위는 해결되고 마지막 질문이 남는데, 이 부분이 가장 실수가 많이 발생하고 연습이 많이 필요한 부분이라고 생각한다.

SRP를 만든 Robert C. Martin(a.k.a uncle bob)의 설명에 의하면

하나의 기능은 한 가지의 변화에 대해서만 변경돼야한다.

이다. 하지만 변화에 대한 이유가 아직까지 모호하다.

코드와 함께 살펴보자

public class Employee {
  public Money calculatePay();
  public void save();
  public String reportHours();
}

코드는 회사의 관점에서 작성되어 있고,

정도로 구성된 클래스가있다.
언뜻보면 Employee클래스는 회사의 구성원에 대한 한 역할만 하는 것으로 이해될 수 있다.
하지만 Bob이 원하는 관점은 다르다.

caculatePay의 기능이 어느날 문제가 생겨서 직원들에게 급여가 잘못 지급되는 문제가 발생했다. 극단적으로 이 책임을 지고 누군가 퇴사를 해야하는 경우가 생기면 누가 퇴사를 해야할까?

애매하다. 그래서 원인을 찾아보니 calculatePay메서드는 기존과 동일하지만 save의 동작이 calculatePay에서 참조하는 변수와 동일해서 예상하지 못한 side-effect이 발생한 것이다.

이를 방지하기 위해 각각의 기능을 클래스로 분리해서 서로 영향이 없게 처리해야한다.

그런데 다시 모호한 부분이 발생한다. 어떠한 기준을 통해 각 기능들을 모듈화할 것인가?
이는 Bob이 방법을 제안한다.

한 사람 혹은 한 그룹에 의해 변경되는 기능끼리 모아야한다. [3]

원문에서는 C-level의 결정권자를 통해 설명한다.

각 메서드별로 변경을 필요로하는 사람이 다르다. 따라서 세 개의 모듈(클래스)로 분리돼야한다.

참고문헌