본문 바로가기
SW

클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 3부 : 설계 원칙 (7장)

by 라꾸스떼(YR) 2020. 3. 1.
반응형

[7장] SRP: 단일 책임 원칙

단일 책임 원칙. 프로그래머가 이 원칙의 이름을 듣는다면 모든 모듈이 단 하나의 일만 해야 한다는 의미로 받아 들이기 쉽다.

헷갈리지 마라. 단 하나의 일만 해야 한다는 원칙은 따로 있다. 그것은 바로 함수는 반드시 단 하나의 일만 해야 한다는 원칙이다. 이 원칙은 커다란 함수를 작은 함수들로 리팩토링하는 더 저수준에서 사용 된다.

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

소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다. SRP가 말하는 ‘변경의 이유’란 바로 이들 사용자와 이해관계자를 가리킨다.

SRP : 하나의 모듈은 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다.

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

이 원칙을 이해하는 가장 좋은 방법은 이 원칙을 위반하는 징후들을 살펴보는 것이다.

 

<징후 1:우발적 중복>

Employee 클래스 - calucatePay()-CFO, reportHours()-COO, save()-CTO

SRP는 서로 다른 액터가 의존하는 코드를 서로 분리하라고 말한다.

 

<징후 2:병합>

메서드가 서로 다른 액터를 책임진다면 병합이 발생할 가능성은 확실히 더 높다.

두 명의 서로 다른 개발자가, 그리고 아마도 서로 다른 팀에 속했을 두 개발자가 Employee 클래스를 체크아웃받은 후 변경사항을 적용하기 시작한다. 안타깝게도 이들 변경사항은 서로 충돌한다. 결과적으로 병합이 발생한다.

모두 많은 사람이 서로 다른 목적으로 동일한 소스 파일을 변경하는 경우가 징후이다. 이 문제를 벗어나는 방법은 서로 다른 액터를 뒷받침하는 코드를 서로 분리하는 것이다.

 

<해결책>

가장 확실한 해결책은 데이터와 메서드를 분리하는 방식일 것이다. 즉, 아무런 메서드가 없는 간단한 데이터 구조인 EmployeeData 클래스를 만들어, 세 개의 클래스가 공유하도록 한다. 각 클래스는 자신의 메서드에 반드시 필요한 소스 코드만을 포함한다.

다른 방법으로는 퍼사드(Facade) 패턴이다. EmployeeFacade에 코드는 거의 없다. 이 클래스는 세 클래스의 객체를 생성하고, 요청된 메서드를 가지는 객체로 위임하는 일을 책임진다.

 

<결론>

단일 책임 원칙은 메서드와 클래스 수준의 원칙이다.

반응형

댓글