이 원칙은 하나의 클래스에 너무 많은 책임을 할당하지 말아야하며 단 하나의 책임 부여를 권장한다.
예를 들어, 하나의 클래스에 몇 가지의 책임이 부여된다면 어떨까? 더 극단적으로 클래스가 아니라 만약 여러 기능을 포함하는 하나의 서비스를 이루는 코드가 하나로 이루어져 있다면, 기능1에서 문제가 생기면 나머지 기능도 동작하지 않는 말도 안되는 일이 발생할 것이다. 이처럼 과한 책임이 할당된 클래스는 영향 범위를 알 수 없으니 코드에 대한 변경이 어렵다. 하지만 클래스 하나에 하나의 책임만 부여되어 있다면 유지보수에서 다른 책임과의 충돌에 대해 걱정하지 않아도 된다.
단일 책임 원칙은 변경과 연결된다. 변경으로 인한 영향 범위를 최소화하는 것이 이 원칙의 목적이다. 따라서 이 원칙을 소개하는 말은 ‘클래스를 변경해야 할 이유는 단 하나여야 한다’가 가장 적합하다.
책임에 대해
나는 책임에 대해 얼마나 알고 있을까. 책임은 너무 추상적이기는 하나 OOP 관점에서의 책임은 어떠한 클래스가 협력을 위해 가지는 고유의 능력이라고 생각한다. 그리고 이는 코드 영역에서 메서드로 구체화 된다. 코드로 예제를 살펴보자
class Developer{
public String createFrontendCode(){...}
public String publishFrontend(){...}
public String createbackendCode(){...}
public String publishBackend(){...}
}코드를 보고 클래스가 어떤 책임을 가지고 있는지 유추해보자. 내 생각에는 세 가지 책임을 가지고 있는 것 같다.
- 프론트엔드 개발자의 책임
- 백엔드 개발자의 책임
- 운영자의 책임
하지만 여기서 프론트엔드 개발자가와 백엔드 개발자가 운영을 함께한다면 책임이 두 가지가 될 것이다.
- 프론트엔드 개발자의 책임
- 백엔드 개발자의 책임
아니다. 만약 풀스택 개발자가 프론트엔드, 백엔드 개발, 운영을 담당한다면 책임은 하나가 된다.
- 1인 스타트업의 풀스택 개발자의 책임
메시지를 전달하는 액터
책임은 메시지를 전달하는 주체가 누구냐에 따라 달라진다. 그것을 액터라고 부른다.
만약 같은 Developer 클래스일지라도, 시스템에 따라 이 클래스를 보고 이해하는 액터 객체는 달라질 수 있다. 이 클래스를 사용하는 액터를 백엔드 개발을 시키는 액터, 프론트엔드 개발을 시키는 액터로 분리한다면 이 클래스의 책임은 두 가지로 본다. 만약 이 클래스를 사용하는 액터가 풀스택 개발을 시키는 액터 하나만 있다면 책임은 한 가지가 된다.
정리하자면 어떤 모듈/클래스가 담당하는 액터가 하나라면 단일 책임 원칙을 지키고 있는 것이며 여럿이라면 위배되는 것이다.
단일 책임 원칙의 목표
- 클래스가 변경될 때 영향을 받는 액터는 하나여야 한다.
- 클래스를 변경할 이유는 유일한 액터의 요구 사항이 변경될 때로 제한되어야 한다.
