SOLID - 단일 책임 원칙(SRP)

Kim, Beomgoo·2022년 8월 31일
0

OOP

목록 보기
1/2

정의

한 클래스는 하나의 책임만 가져야 한다. 클래스는 그 책임을 완전히 캡슐화해야 한다. 클래스가 제공하는 모든 기능은 이 책임과 주의 깊게 부합해야 한다.

하나의 객체가 해야 할 일이 많아지면, 즉 책임이 커지면, 이 객체에 변경이 일어날 경우 어플리케이션에 미치는 영향이 커질 가능성이 높다. SRP는 이러한 의존성을 줄이는 것이 목적이다.

SRP를 위배하는 코드

public class Calculator {
	
	int sum(int x, int y) {
		return x + y;
	}

	int subtract(int x, int y) {
		return x - y;
	}

	LocalDateTime currentDateTime() {
		return LocalDateTime.now();
	}
}

계산기 역할을 하는 클래스 Calculator를 만들었고, 간단한 덧셈을 하는 sum과 뺄셈을 하는 subtract, 그리고 현재 시간을 알려주는 currentDateTime 메소드를 구현하였다.

관심사의 분리

하나의 클래스는 하나의 책임을 가져야 한다. 그러기 위해서는 클래스의 관심사가 하나이거나 최대한 작은 범위여야만 한다. Calculator 클래스의 관심사는 ‘수의 계산'이다. 따라서 sumsubtract는 메소드로 가져도 SRP에 부합하는 것으로 보인다.

그러나 ‘현재 시간'을 알려주는 currentDateTime 메소드는 ‘수의 계산'이라는 관심사와 동떨어져 보이고, 오히려 ‘시계'같은 것이 클래스의 관심사로 가지는 것이 합당해 보인다. 이를 클래스를 분리해 관심사를 분리해보자.

SRP를 준수하도록 리팩토링한 코드

public class Calculator {
	
	int sum(int x, int y) {
		return x + y;
	}

	int subtract(int x, int y) {
		return x - y;
	}
}

public class Clock {
	LocalDateTime currentDateTime() {
		return LocalDateTime.now();
	}
}

시계 역할을 하는 클래스 Clock을 새로 추가하여 관심사를 분리하였다.

SRP를 준수했을 때의 이점

  • 객체가 가지는 책임이 간결하고 명확해진다.
  • 모듈에 대한 의존성이 낮아져 수정 시 어플리케이션에 미치는 영향을 줄여준다.
  • 코드가 간결해져 유지보수가 용이해진다.

참고

‘단일'이라는 것은 상대적인 의미로, 클래스 하나당 동작 하나만 가져야 한다는 뜻은 아니다. 그 자체로 유의미한 책임을 되도록 작은 단위로 갖게 설계하라는 것이지만, 너무 과도하게 분리하는 것은 오히려 코드의 복잡성을 증가시키는 부작용을 낳는다.

profile
하나에 하나를 보탠다

0개의 댓글