Single-responsibility principle (SRP)

SRP 란?

처음 SRP를 접하면 흔히 할 수 있는 실수가 "모든 모듈은 단 하나의 역할만 해야 한다"는 의미로 받아들이기 쉽다.

하지만 SRP는 위와 같은 의미가 아니며, SRP라는 용어를 소개한 Robert C. Martin은 SRP를 이렇게 정의내렸다.

하나의 모듈은 하나의 액터에 대해서만 책임져야 한다

여기서 모듈과 액터에 대해서 알아야 할 것 같다.

• 모듈

  모듈은 일반적으로 소스 파일이라고 정의할 수 있지만, 좀 더 정확히 정의하면 함수와 데이터 구조로 구성된 응집된 집합이라고 할 수 있다.

• 액터 (나는 사용자라는 표현이 와닿는다.)

  액터는 해당 변경을 요청하는 한 명이상의 사람들을 가리킨다.

SRP 위반 사례 (우연한 중복)

Robot 이라는 클래스를 만들어서 S 회사에 팔았다고 가정해보자.

public class Robot {
	
	public double calculateSalary(int time) {
		return bonus(time) * 0.85;
	}
	
	public boolean addOvertimePay(int time) {
		return bonus(time) - 20 > 0;
	}
	
	public int recordCommute(int startTime, int endTime) {
		return endTime - startTime;
	}
	
	private int bonus(int time) {
		return time + 10;
	}
	
}

여기서 Robot의 메서드는 3개가 존재하는데,

S 회사의 a팀은 calculateSalary만 사용
S 회사의 b팀은 addOvertimePay만 사용
S 회사의 c팀은 recordCommute만 사용

위와 같다면 Robot이라는 하나의 클래스는 3개의 액터를 갖게 되고 SRP를 위반하게 되는 것이다.

위 클래스를 살펴보자.

메소드 calculateSalary와 addOvertimePay가 bonus라는 method를 공유하고 있는 것을 볼 수 있는데, a팀이 bonus를 증가시켜달라는 요청을 했다고 가정해보자.

bonus 메소드를 수정하고 난 뒤 개발자는 calculateSalary에 bonus라는 메소드가 사용된 것을 알게 되었다.

하지만 addOvertimePay 메소드에는 사용되었다는 것을 알지 못했다면 어떻게 될까?
증가된 보너스로 인해 b팀은 손실을 얻게 될 것이다.

해결

이 문제의 해결책은 다양한데, 그 중의 하나는 각 메서드를 다른 클래스로 분리시키고 클래스는 서로의 존재를 모르면 '우연한 중복' 문제를 피할 수 있다.

하지만, 이 해결책도 클래스를 인스턴스화하고 추적해야 하는 단점이 있어서 퍼사드 패턴을 이용하는 방법이 있다. (퍼사드 패턴은 이 글에서 다루지 않고 추후에 정리할 예정이다.)