단일 책임 원칙 , 가장 의미가 잘 전달되지 못한 원칙이다. 프로그래머가 이 원칙의 이름을 듣는다면 모든 모듈이 단 하나의 일만 해야 한다는 의미로 받아들이기 슆다.
헷갈리지 말라. 단 하나의 일만 해야 한다는 원칙은 따로있다. 그것은 바로 함수는 반드시 하나의 , 단 하나의 일만 해야 한다는 윈칙이다. 이 원칙은 커다란 함수를 작은 함수들로 리팩터링 하는 더 저수준에서 사용된다. 하지만 이 원칙은 SOLID 원칙이 아니며 , SRP 도 아니다.
SPR 는 아래와 같이 기술되어 왔다.
<aside> 😃 단일 모듈은 변경의 이유가 하나, 오직 하나뿐이여야 한다. ( 하나의 모듈은 하나의 , 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다. )
</aside>
여기서 이해관계자와 사용자는 집단 , 변경을 요청하는 한 명 이상의 사람들을 가리킨다.
해당 원칙을 위반하는 징후들을 살펴보자
( 필자는 급여 어플을 예로 들었지만.. 게임으로 할만한걸 생각해봤다. )
class GameModeSystem
{
private:
void DeathMatchPlay();
void SurvivalPlay();
void HardCorePlay();
}
여기서 개발자가 이 세 메서드를 GameModeSystem 이라는 단일 클래스에 배치해서 세 기획자 ( 데스매치 기획자 , 서바이벌 기획자 , 하드코어 기획자 ) 가 서로 결합되어 버렸다.
이 결합으로 인해서 서바이벌 기획이 결정한 조치가 다른 기획자한테 영향을 줄 수 있다.
예를들어 데스매치 함수와 Survival 함수가 자기장이 줄어드는 알고리즘을 사용한다고 치자. 그럼 개발자는 코드 중복을 피하기 위해 MoveMagnaticField() 라는 알고리즘을 사용했다.
근데 갑자기 데스매치 기획 쪽에서 자기장이 조금씩 다르게 만들어 달라는 요청을 하고 해당 함수를 고친다면 서바이벌 모드에서도 분명 문제가 일어날 것 이다.
( 협업을 한다면 나는 이 둘을 다 맡지 않고 따로 설계했을 수 있으며 , 만약 그렇게 되면 한 사람이 수정한걸 [ 내가 데스매치 수정 ] 다른 사람이 설계한 모드가 망가질 수 있음 )
해당 문제는 서로 다른 액터가 의존하는 코드를 너무 가까이 배치했기 때문에 발생한다.