[Books] 하나의 객체는 하나의 책임만 가져야 한다?

 

1객체 1책임 == 단일 책임 원칙

SRP(Single Responsibility Principle)란?
하나의 클래스는 단 한 개의 책임을 져야 한다는 의미이다.

만약 하나의 클래스가 하나 이상의 책임이 있다면, 이것은 결합(Coupled)을 불러오게 되며 추후 하나의 책임에 대한 변경이 생겼을 때 결합으로 인해 다른 책임까지 수정을 발생시키게 된다.

 

 

책임의 기준이 뭔데?

한 가지 책임의 기준은 뭘 의미하는 걸까?

여기서 말하는 단일 책임은 절대적으로 측정할 수 있는 개념이 아니라 상대적이기 때문에 기준이 모호하다. 어느 정도의 수준으로 추상화를 하느냐에 따라서 ‘단일’로 볼 수도 있고 아닐 수도 있다.

하지만, SOLID 원칙의 창시자인 Robert C. Martin은 단일 책임 원칙에 대해 같이 수정해야 될 것들은 묶고 따로 수정해야 될 것들은 분리하는 것으로 기준을 정했다. 이를 기반으로 '단일 책임 원칙'을 다음과 같이 재정의한다면 기준을 세우고 설계하는데 용이할 수 있다.

"클래스(모듈)를 변경하는 이유는 단 한 가지여야 한다.”

 

 

단일 책임 원칙의 오해

🤔 메서드의 개수 ≠ 책임의 개수

하나의 클래스에 메서드가 3개라고 책임이 3개인 것은 아니다.

단일 책임 원칙은 '하나의 모듈은 하나의 일만 해야 한다'는 의미로 자주 오해되곤 한다. 이는 흔히 알려진 '하나의 함수는 하나의 일만 해야 한다'는 원칙과의 혼용되어 발생한 오해인 듯싶다. 위의 원칙은 함수를 설계할 때 사용되는 원칙으로 단일 책임 원칙보다 저수준에서 사용된다.

'단일 책임 원칙'은 위에 언급한 정의처럼 '클래스(모듈)를 변경하는 이유는 단 한 가지여야 한다'라는 의미로 하나의 '일'만 하는 것이 아니라 '수정 이유가 같은 것들을 묶는다'로 이해하는 것이 가까울 것 같다.

 

 

그래서 이걸 왜 사용해야 하는데?

단일 책임 원칙이 잘 적용되어 있다는 것은 각 클래스의 수정 이유가 단 한 가지라는 뜻이다.

즉, 특정 기능을 수정할 때 하나의 클래스만 수정하면 되기 때문에 유지보수가 편리해진다. (만약 단일 책임 원칙이 잘 지켜지지 않았다면 여러 개의 클래스를 수정해야 할 것이다.)

또한 단일 책임 원칙에 따라 하나의 클래스가 하나의 책임만을 맡는다면 이후에 기능을 수정할 때 발생할 수 있는 사이드 이펙트를 막을 수 있다.

💡 코드가 더 길어지는데요?! 그냥 하나에 때려 박으면 안 되나요?!
단일 책임 원칙을 적용하면서 기존 코드보다 길이가 더 길어질 수도 있다. 하지만 전체 코드의 길이가 길어졌다 하더라도 하나의 클래스를 사용하는 것보다 여러 개의 클래스를 사용하는 것이 더 효율적이다. 그래야 각 클래스의 의미를 파악하기도 쉽고 유지보수에 용이하기 때문이다.

 

 

오늘의 결론

단일 책임 원칙을 잘 지켰는지 판단하는 것은 쉽지 않다.
개발자의 생각이 제각기 다르고 프로그램의 특성도 다르기 때문에 정해진 답은 없다.
다만 중요한 것은 코드를 작성할 때, 단일 책임 원칙을 잘 지켰는지 생각해 보는 것이다.
하나의 클래스에 너무 많은 책임이 있는 건 아닌지, 분리할 수 있는 변수와 함수가 많지 않은지 항상 고민하자!

 

 

 

 

※ 이 내용은 책 [스프링 입문을 위한 자바 객체 지향의 원리와 이해]를 보고 정리한 내용입니다.