SOLID in Action — 단일 책임 원칙

Dec 24 2022

"클래스에는 변경해야 할 단 하나의 이유가 있어야 합니다."

우리는 "Jack of all trades, master of none"이라는 말을 알고 있습니다. 우리는 수신 측에 있을 때 그것을 싫어합니다.

Unsplash의 Robert Linder 사진

우리는 "Jack of all trades, master of none"이라는 말을 알고 있습니다. 우리는 수신 측에 있을 때 그것을 싫어합니다. 사랑하는 사람에게 하는 말을 우리도 싫어합니다. 그것은 우리가 사랑하는 것에 도 적용되어야 합니다 .

우리 개발자들은 우리가 만든 코드를 좋아합니다. 우리는 우리가 작성하는 기능, 우리가 디자인하는 클래스, 구성 요소, 시스템 및 마이크로 서비스… 우리가 개발하는 것을 자랑스럽게 생각합니다. 따라서 우리는 그들이 "Jack of all trades, master of none"이 되는 것을 좋아하지 않을 것입니다.

따라서 우리는 새로운 창작물을 작업할 때 단일 책임 원칙(SRP)을 항상 염두에 두어야 합니다.

이 원칙에는 두 가지 버전이 있습니다.

각 클래스에는 단일 책임이 있어야 합니다.
클래스는 변경해야 하는 단 하나의 이유를 가져야 합니다.

재사용 가능, 유지 관리 및 이해 가능

첫 번째 기사 에서 나는 이메일을 보내고 주문 상태 를EmailService 업데이트하는 것이 아니라 이메일을 보내는 데만 관심을 가져야 한다고 제안합니다 .

EmailService 및 해당 연결

이점은 여러 가지입니다.

EmailService더 재사용 가능 합니다. StockManagementService"재고 부족" 이메일 알림을 발생시키도록 호출할 수도 있습니다.
EmailService유지 보수 가 더 쉽습니다 . 우리는 한 가지 sendEmail(EmailContent)방법만 처리하면 됩니다. 주문 관리 로직을 알 필요도 없고 새로운 상태를 추가하기 위해 어떻게 변경될지 걱정할 필요도 없습니다.
EmailService더 이해 하기 쉽습니다 . 한 줄의 코드를 보지 않고도 이메일 전송만 담당한다는 것을 자신있게 알고 있습니다.

애플리케이션이 커짐에 따라 사용자는 더 많은 것을 요구합니다. 이메일은 예를 들어 HTML, 디자인 이미지 및 CSS와 같은 더 나은 형식이어야 합니다. 개발팀은 복잡한 이메일 디자인을 코드로 하드코딩하는 대신 템플릿 파일에 캡처하기로 결정했습니다.

주문 확인(스크린샷)

EmailContent이제 2개의 새 필드를 포함하도록 확장되었습니다. a templateName는 템플릿 파일의 이름을 포함하고 템플릿 templateValues에 정의된 자리 표시자의 값을 포함합니다(예: 에 customerName매핑 Huy, 에 orderAmount매핑 42.90, 에 orderCurrency매핑 SGD) .

data class EmailContent (
   // existing fields
   val fromEmail: String, 
   val toEmail: String, 
   val ccEmail: String,
   val emailBoy: String,
   // new fields
   val templateName: String,   
   val templateValues: Map<String, Object> 
)

interface EmailService {
    fun sendEmail(content: EmailContent): String
    fun sendEmailWithTemplate(content: EmailContent): String    
}

이 위반은 여전히 쉽게 발견할 수 있지만 일반적인 함정입니다. 원래 디자인이 아무리 좋아도 기능의 발전은 종종 SRP 위반과 관련됩니다.

덜 악

사업이 번창하고 주문 방식이 2개 더 추가되었습니다. 원래 장바구니 주문 외에도 제휴사 또는 월간 반복 구독에서 주문이 올 수 있습니다. 어떤 모드에 관계없이 고객은 주문이 생성되고 신용 카드로 청구될 때 확인 이메일을 기대합니다.

3개의 다른 클래스에서 확인 이메일을 생성하고 보내는 코드를 반복하지 않기 위해 팀은 코드를 EmailService의 sendOrderConfirmation(OrderDetail)방법 으로 옮기기로 결정했습니다.

코드 중복을 피하거나 SRP에 충실하십시오.

이것은 명백한 SRP 위반이지만 강력한 정당성이 있습니다. 덜 나쁜 것, 3개 클래스의 코드 중복 또는 1개 더 많은 책임이 있는 것은 EmailService무엇입니까?

선집적 책임

Coen 형제 의 선집 영화 The Ballad of Buster Scruggs를 보셨나요? 6편의 짧은 서부 이야기 모음집입니다.

유추하여 선집 수업을 합시다. 아마도 가장 좋은 예는 유틸리티 클래스일 것입니다.

공통 주제는 일반적으로 더 큰 그룹 내의 개별 이유를 연결합니다. 예를 들어 StringUtils 는 많은 문자열 조작 메서드를 수집합니다.

명확한 주제가 없다면? A MiscellaneousUtils(또는 짧은 형식 MiscUtils)가 좋습니다.

결론

단일 책임 원칙은 많은 이점을 제공합니다. 재사용 가능성, 유지 관리 가능성 및 이해 가능성은 그 중 일부에 불과합니다.

불행히도 SRP는 항상 달성하거나 유지 관리할 수 있는 것은 아닙니다. 우리는 좋은 초기 디자인에도 불구하고 위반이 계속 발생하는 두 가지 시나리오를 분석했습니다.

이러한 위반 사항을 해결하는 방법에 대해서는 논의하지 않았습니다. 문제를 해결하는 것은 시간이 지남에 따라 모든 팀이 축적하는 기술적 부채를 해결하는 것만큼 어렵기 때문에 의도적으로 그렇게 한 것입니다.