SRP(단일 책임 원칙)

클래스를 변경하는 이유는 단 한 가지여야 한다.

단일 책임 원칙(SRP: Single Responsibility Principle)은 다섯 가지 SOLID 애자일 원칙 중 하나입니다.

클래스를 변경하는 이유가 한 가지이기 위해서는 하나의 액터에 대한 책임만 가지고 있어야 합니다.

여기서 책임은 하나의 특정 액터를 위한 기능 집합이고, 액터란 기능(=클래스 ,모듈)을 사용하는 주체

Responsibility(책임)

-SW의 변경을 요청하는 특정 사용자들에 대해 클래스/함수가 갖는 것 “변경의 원인”

→ 변경의 원인이 같은 것들은 같은 책임

-SRP에서는 메소드의 변경을 유발하는 사용자에 의해 분류함

사용자(User)

-사용자들은 그들이 수행하는 Roledp 따라 나눠야한다.

-사용자가 특정 역할을 수행할 때 Actor라고 부른다. → 책임은 개인이 아니라 액터와 연결

ex) 아래 클래스에는 3개의 액터가 있다.

• Policy
• Architect
• Operations

SRP에서 책임은 특정 액터의 요구사항을 만족시키기 위한 일련의 함수의 집합이다.

액터의 요구사항 변경이 일련의 함수들의 변경의 원인이 된다.

 

SRP가 필요한 문제점

1.Collision(충돌)

여러개의 액터가 다른 함수의 변경을 필요로함 → 동일모듈의 충돌이 일어남(병합 충돌, 소스 저장소 충돌)

2.Fan-Out

• Employee가 DBApi, CalculationAPI, StringAPI 모두를 사용     
• → 변경하기 어려워짐 Employee 클래스에 거대한 Fan out이 발생

• Fan Out을 제한하는 방법

→ 책임을 최소하하는 것: 3가지 책임이 아닌 1가지 책임만 갖게하는 것이 SRP

3.Collocation is Coupling

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

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

 

SRP 적용 방법

• 시스템 설계
• Actor 파악에 주의해야함

위 그림의 3개의 Actor, 3개의 책임이 하나의 클래스에 있다 SRP를 적용하여 분리하는 방법

1.Inverted Dependencies

• 클래스를 인터페이스와 클래스로 분리
• 문제점
• - 모든 Actor들이 하나의 인터페이스에 결합되어 있고, 하나의 클래스에 구현되어 구현도 결합도가 높음

2.Extract Class

• 3개의 클래스로 분리하여 3개의 책임을 분리한다.
• Actor들은 분리된 3개의 클래스에 의존
• 3개의 책임에 대한 구현 분리
• 하나의 책임의 변경이 다른 책임에 영향X

문제점

• Employee의 로직이 바뀌면 EmployeeGateWay/EmployeeReporter에 영향을 끼칠 수 있음(transitive dependency)

 

Inverted Dependencies 과 Extract Class를 합치면 더 좋은 SRP 구조가 생성

 

인터페이스를 분리하는 방법

 

Interface Segregation

• 3개의 각각의 인터페이스를 하나의 클래스로 구현
• 장점

-Actor들의 결합을 완전히 없앨 수 있다.

• 단점

-어디에 구현되었는지 찾기 어렵다.

-하나의 클래스에 구현되어 구현은 결합돼있다. → 클래스(Impl)도 3개로 나눔

 

결론

SRP는 변경으로 버그가 발생하더라도 다른 관련 없는 동작에 영향을 미치지 않도록 동작을 분리하는 것을 목표로 합니다.

클래스나 모듈이 서로 다른 이유로 변경되기 시작한다면 SRP를 따르도록 분리해야 합니다.

하지만 SRP에 대한 과도한 고려는 더 나은 설계 대신 이해하기 힘든 설계로 이어질 수 있으니 과도하게 사용하면 안 됩니다.

 

출처: https://youtu.be/AdANHDp5dTM