SRP - 단일 책임 원칙

SRP는 총 5가지 디자인 원칙을 묶은 니모닉 약어인 SOLID의 일부입니다.

그러나 SRP는 무엇이며 중요하며 관심을 가져야 합니까?

그것은 무엇을 진술합니까?

지금은 제 나름대로 정의를 내릴 수 있지만, 로버트 C. 마틴은 이 원칙에 대해 처음 썼을 때 이미 아주 훌륭한 정의를 내렸습니다.

"A class should have one, and only one, reason to change"

그는 클래스를 구체적으로 언급했지만 모듈과 기능에도 원칙을 적용할 수 있습니다.
따라서 클래스, 모듈 또는 함수가 있을 때 그 안의 코드를 변경하는 데는 정확히 한 가지 이유가 있어야 합니다.

둘도 아니고 셋도 아닌 하나!

기본 예

보고서 데이터를 생성하는 함수인 아주 기본적인 예를 살펴보겠습니다. 그리고 보시다시피 이 기능에는 문제가 있습니다. 그것은 한 가지 이상의 일을 합니다!

function createReportData(user) {
  const lowerCasedForename = user.forename.toLowerCase();
  const capitalizedForename = lowerCasedForename.charAt(0).toUpperCase() + lowerCasedForename.slice(1);
  const greeting = `Hello ${capitalizedForename}!`;
  return {
    id: user.id,
    name: user.name,
    forename: user.forename,
    greeting
  };
}

인사말을 변경하려면 어떻게 합니까?
=> 바꿔야 합니다 createReportData !

보고서에 데이터를 추가하려는 경우 어떻게 됩니까?
=> 바꿔야 합니다 createReportData !

왜 중요 함?

SRP는 코드를 다음과 같이 만듭니다.

1. 테스트 가능

코드는 정확히 한 가지만 테스트하면 되므로 테스트하기가 더 쉽습니다.

2. 재사용 가능

인사말을 만들기 위해 논리를 재사용하고 싶다고 상상해 보십시오.
createReportData를 사용하시겠습니까?

SRP를 활용하면 주문형으로 구성할 수 있는 작은 독립 장치를 갖게 됩니다!

3. 가독성

한 가지만 수행하는 단위는 크기가 더 작을 가능성이 높으므로 특히 일반적으로 관련된 설명적인 이름이 있기 때문에 더 읽기 쉽습니다.

4. 리팩토링 가능

단위가 작고 각각이 한 가지 일만 잘하면 리팩토링하기가 훨씬 쉽습니다.

처음 5개에만 관심이 있을 때 다른 작업을 수행하는 다른 50개 라인을 처리할 필요가 없습니다!

SRP 적용

각각의 책임이 있는 개별 기능을 생성하여 위의 예를 수정할 수 있습니다.

다음 코드 스니펫을 보면 어떻게 보일지 알 수 있습니다.

function createGreeting(forename) {
  const lowerCasedForename = forename.toLowerCase();
  const capitalizedForename = lowerCasedForename.charAt(0).toUpperCase() + lowerCasedForename.slice(1);
  return `Hello ${capitalizedForename}!`;
}

function createReportData(user) {
  const greeting = createGreeting(user.forename);
  return {
    id: user.id,
    name: user.name,
    forename: user.forename,
    greeting
  };
}

변경 사항 분석

무슨 일이에요?

인사말 문자열을 만드는 논리는 이제 별도의 기능입니다.
인사말이 변경되면 변경 사항을 적용할 위치입니다!
createReportData는 인사말이 보고서 데이터의 일부이기 때문에 이제 createGreeting만 사용합니다.
기능 자체는 이제 보고서 데이터를 추가, 제거 또는 변경하려는 경우에만 변경하면 됩니다.

그리고 추가 보너스로:
테스트 케이스가 더 분리되고 독립적이 됩니다!

신경써야 하나?

SRP는 일반적으로 적용하기 쉬운 원칙 중 하나이기 때문에 SRP에 대해 확실히 관심을 가져야 합니다.
항상 한 가지 질문을 할 수 있기 때문에 코드를 분할하는 데 많은 에너지가 들지 않습니다.

"이걸 언제 바꿔야 합니까?"

답이 둘 이상일 때마다 코드를 여러 기능으로 분할할 수 있고 분할해야 한다는 것을 알고 있습니다!

여기에서 읽은 것처럼 SRP에는 많은 이점이 있습니다.
=> 적은 비용으로 가지고 다니지 않겠습니까?

가기 전에

내 콘텐츠가 마음에 든다면 에서 나를 방문하세요. 그러면 아마도 당신이 보는 것을 좋아할 것입니다!