SRP (Single Responsibility Principle)

책임(Responsibility)

클래스는 하나의 책임을 가져야 한다. 여기서의 책임은 무엇인가?

• save/findById는 같은 부류 (DB와 관련된 기능)

• 같은 책임을 갖는 기능은 추가해도 책임의 수는 변하지 않음

• 같은 부류로 나눠서 책임이 몇 개인지 결정되는 것

여기서의 부류란,

• 메서드의 Client에 의해 결정된다. (메서드를 누가 사용하는가?)

• 누가 해당 메서드의 변경을 유발하는 사용자인가?

  • 메서드의 변경을 유발하는 사용자를 액터(Actor)라고 한다.

It's About Users

SRP는 사용자에 관한 것이다.

책임(Responsibility)은 소프트웨어의 변경을 요청하는 특정 사용자들에 대해 클래스/함수가 갖는 것으로 "변경의 근원"으로 볼 수 있다.

여기서 Employee 클래스의 변경을 요구하는 사용자 그룹을 나눠볼 수 있다. 이 사용자 그룹은 액터(Actor)가 되며 서로 다른 니즈(Needs)가 존재하기에 각 책임을 잘 나눌 수 있어야 한다.

It's About Roles

• 유저들을 그들이 수행하는 역할(Role)에 따라 나눠야 한다.

• 유저가 특정 역할을 수행할 때 액터(Actor)라고 부른다.

  • 책임은 개인이 아니라 액터와 연결된다.

• Employee 클래스에는 3개의 액터(Policy, Architect, Operations)가 있다.

객체지향에서 강조하는 "책임을 잘 할당해야 한다"에서의 책임은 특정 액터의 요구사항을 만족시키기 위한 일련의 함수의 집합이며 액터의 요구사항 변경이 일련의 함수들의 변경 근원이 된다.

소프트웨어의 2가지 가치

Primary Value

• 지속적으로 변화하는 요구사항을 수용하는 것

• 대부분의 소프트웨어는 현재 요구사항을 잘 만족하지만 변경하긴 어렵다.

Secondary Value

• 현재 소프트웨어가 사용자의 현재 요구사항을 만족하는가?

액터가 변경의 근원이므로 액터를 잘 관리해야 한다. 위의 Employee에서는 Primary Value를 잘 만족하고 있는가?

충돌 문제(Collision)

- Policy Actors: 비즈니스 규칙의 변경을 필요로 함.
- Architect Actors: DB Schema 변경을 필요로 함.
- Operations Actors: 비즈니스 규칙의 변경을 원함.

하나의 모듈에 여러 변경이 일어나 충돌이 발생한다 !!

팬 아웃 문제(Fan Out)

Employee는 너무 많은 것을 알고 있는 상태이다. 거대한 Fan Out이 존재하는 것이다. 많은 팬 아웃은 많은 책임을 갖게되며 각각의 책임은 Employee가 다른 클래스들을 사용하도록 한다.

책임을 최소화하여 Fan Out을 제한하자.

Collocation is Coupling

Operations Actor가 새로운 리포트 기능을 필요로 했다고 가정해보자. 새로운 리포트 기능도 Employee 클래스에 추가했다면 어떤 문제가 발생할까?

새로운 기능이 추가된 Employee 클래스의 영향이 Employee 클래스를 사용하는 모든 클래스들이 다시 컴파일되고 배포되어야 한다.

SRP

하나의 모듈은 반드시 하나의 변경 사유를 가져야 한다.

• 하나의 클래스는 한 종류의 클라이언트에게만 서빙해야 한다.

• 동일한 이유로 변경되어야 하는 것들은 동일 모듈에

• 다른 이유로 변경되어야 하는 것들은 다른 모듈에

유스케이스를 기반으로 시스템 설계할 때 액터(Actor)들을 파악하게 된다. 이 때 SRP를 통해 각 모듈이 반드시 하나의 책임을 갖도록 유지하며 책임을 모듈에 할당해야 한다.

해결 방안(Solution)

1. 의존성 역전(Inverted Dependencies)

• OOP에서 의존성을 다루는 전략으로 클래-스를 인터페이스(interface)와 구현 클래스로 분리한다.

• 액터를 클래스에서 디커플링하게 된다.

  • 액터들에 변경사항이 존재한다고 하더라도 Employee 라는 인터페이스의 변경이 없다면 다른 액터들은 영향을 받지 않는다.

2. 클래스 분리(Extract Class)

• 3개의 책임을 갖는 3개의 클래스로 분리

• 액터들은 분리된 3개의 클래스에 의존

• 하나의 책임의 변경에 다른 책임에 영향을 미치지 않음

문제점

• transitive dependency: Employee의 변경이 잠재적으로 모든 액터에게 영향을 미칠 수 있다.

• Employee의 개념이 각각의 조각으로 분리되어 기능이 어디에 구현되어있는지 찾으러 다녀야 함.

1번과 2번을 합친 방법도 고려해보자.

1. 클래스를 인터페이스로 추출

2. 1개의 인터페이스를 3개의 인터페이스로 분리

3. 3개의 인터페이스를 구현

3. 퍼사드(Facade)

• 모든 함수들을 Facade Class에 두고, 각 기능에 맞는 액터들에게 위임하는 형태

• 어디에 구현되어있는지 찾기 쉽지만, 여전히 기능들에 대한 어떠한 변경이라도 있다면 모든 액터들에 영향을 미칠 수 있다.

4. 인터페이스 분리 (Interface Segregation)

• 각각의 인터페이스를 하나의 클래스로 구현하는 방식

• 액터들은 완전히 decoupled 되지만, 어디에 구현되어있는지 찾기 어려우며, 하나의 클래스에 구현되어 구현은 coupled

---

결론 및 요약

• 책임은 사용자(액터)에 따라 결정된다.

• SRP는 하나의 변경 사유(액터)만 가져야 한다는 원칙을 말한다.

• 책임을 잘 나누면 변경에 유연해지도, 충돌과 팬 아웃을 줄일 수 있다.

• 의존성 역전, 클래스 분리, 퍼사드, 인터페이스 분리 등의 방법으로 SRP를 실천할 수 있다.

  • 다만, 적절한 책임을 가지게 하는 것은 정말 어려운 분야이다. 실전 감각이 필요!

클래스는 하나의 액터(변경의 근원)만을 위해 존재해야 하며, 액터별로 책임을 분리하면 변경에 유연한 소프트웨어가 된다.