7장 - SRP : 단일 책임 원칙

단일 책임 원칙의 오해

모듈이 단 하나의 일만 해야 한다는 의미로 받아들이기 쉽습니다.

 

하지만 역사적으로 다음과 같은 의미를 가집니다.

 

단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다.

 

변경의 이유는 사용자와 이해관계자를 가리킵니다.

사용자나 이해관계자가 여러 명일 수 있기 때문에 이런 의미보다는 변경을 요청하는 한 명 이상의 사람들을 가리키며 이러한 집단을 엑터라 합니다.

 

다시 말해 하나의 모듈(소스 파일)은 하나의 액터에 대해서만 책임져야 합니다.

 

SRP 위반 예시

중복을 허용하자

Employee 클래스는 calculatePay(), reportHours(), save()를 가집니다.

세 가지 메서드는 매우 다른 세명의 액터를 책임집니다.

calculatePay - 회계팀에서 기능을 정의

reportHours - 인사팀에서 기능을 정의

save - DBA가 기능을 정의

 

이때 중복을 제거하기 위해 calculatePay 메서드를 둘 이상에서 사용하였을 때, calculatePay가 변경되었을 때 다른 곳에서 사이드 이펙트라 터질 수 있습니다.

 

이런 문제는 서로 다른 액터가 의존하는 코드를 너무 가까이 배치했기 때문에 발생하였으며 이를 분리해야 합니다.

 

코드 병합 과정에서 발생하는 문제

서로 다른 조직이 만약 하나의 파일을 다른 목적으로 수정하게 될 수 있습니다.

여기서 벗어나기 위해서는 서로 다른 액터들에게 각각 코드를 분리시켜야 합니다.

해결책

모든 메서드를 각기 다른 클래스로 이동시키는 방식으로 해결합니다.

또한 세 클래스는 서로의 존재를 몰라야 합니다.

이를 통해 우연한 중복을 피할 수 있습니다.

 

하지만 세 가지 클래스를 인스턴스화 하고 추적해야 합니다.

이런 난관속에서 퍼사드 패턴을 사용하게 되면 하나의 클래스에서 간편하게 호출하여 사용할 수 있습니다.

 

개인적인 견해

변경의 이유가 하나라는 말이 와닿지 않았는데 회계팀, 인사팀, DBA 예시가 와닿았습니다.

 

해결책에서 메서드를 다른 클래스로 이동시키는 방식이라고 하는데 이렇게 분리만 한다고 해서 해결이 될지?

 

예를 들어 메서드가 다른 클래스로 래핑 되어 호출된 것 밖에 없는 것 같은데 이 클래스를 서로 다른 엑터가 관여하면 결국 문제가 발생하지 않을까 생각합니다.

 

따라서 이를 해결하기 위해서 단지 어느정도 일부러 중복을 허용해야 해결할 수 있는 것 아닌지?

 

예를 들어 하나의 메서드에 서로 다른 엑터가 관여한다면 중복을 허용하더라도 2개의 메서드로 분리해야 할 것 같다고 생각합니다.

 

-> 클래스로 래핑함으로 이해했는데 인터페이스로 이해를 하는 것이 좋습니다. 따라서 우발적 중복을 인터페이스의 구현체를 여러개 두어서 구현하면 SRP원칙을 지킬 수 있습니다.

 

출처

https://snowdeer.github.io/designpattern/2016/05/13/design-pattern-facade/

퍼샤드(Facade) 패턴 · snowdeer's Code Holic