더 나은 소프트웨어를 설계하고 If-Else를 대체하는 5가지 방법. 초급부터 고급까지의 예

이것만 말씀드리죠: If-Else는 일반적으로 나쁜 선택입니다.

디자인이 복잡해지고 코드 가독성이 떨어지며 리팩토링이 어려워질 수 있습니다.

그러나 If-Else는 사실상의 코드 분기 솔루션이 되었으며 이는 의미가 있습니다. 이것은 모든 야심 찬 개발자에게 가장 먼저 가르치는 것입니다. 불행하게도 많은 개발자들은 더 적절한 분기 전략을 추진하지 않습니다.

어떤 사람들의 진언은 다음과 같습니다: If-Else는 망치이고 모든 것은 못입니다.

언제 더 적절한 방법을 사용해야 할지 판단하지 못하는 것도 후배와 후배를 구별하는 것 중 하나입니다.

이 끔찍한 연습에 종지부를 찍을 몇 가지 팁과 패턴을 보여 드리겠습니다.

예를 들 때마다 난이도가 높아집니다.

1. 완전히 불필요한 Else 블록

이것은 아마도 후배 개발자들이 저지르는 가장 큰 죄 중 하나일 것입니다. 아래 예는 If-Else가 훌륭하다는 말을 들었을 때 어떤 일이 발생하는지 보여주는 좋은 예입니다.

이 프로세스를 단순화하려면 else` 블록을 제거하기만 하면 됩니다.

더 전문적으로 보이죠?

실제로는 다른 블록이 전혀 필요하지 않다는 것을 알게 될 것입니다. 이 경우처럼 특정 작업을 수행하고 특정 조건이 충족되면 즉시 반환하고 싶습니다.

2. 값 할당

제공된 일부 입력을 기반으로 변수에 새 값을 할당하는 경우 더 읽기 쉬운 접근 방식인 If-Else 넌센스를 중지하세요.

간단하지만 형편없습니다. 첫째, If-Else는 여기서 스위치로 쉽게 교체할 수 있습니다. 그러나 else를 완전히 제거하면 이 코드를 더욱 단순화할 수 있습니다.

else를 사용하지 않으면 깨끗하고 읽기 쉬운 코드가 남습니다. 또한 단일 반환 문이 아닌 빠른 반환으로 스타일을 변경했습니다. 올바른 값이 이미 발견된 경우 값을 계속 테스트할 필요가 없습니다.

3. 전제 조건 확인

일반적으로 메서드가 잘못된 값을 제공하면 실행을 계속하는 것이 의미가 없다고 생각합니다.

제공된 입력 값이 항상 0 또는 1이어야 하는 이전의 DefineGender 메서드가 있다고 가정합니다.

값 유효성 검사 없이 메서드를 실행하는 것은 의미가 없습니다. 따라서 메서드 실행을 계속하기 전에 몇 가지 전제 조건을 확인해야 합니다.

가드절 방어코딩 기법을 적용하여 메소드의 입력값을 확인한 후 메소드를 계속 실행하게 됩니다.

이 시점에서는 값이 예상 범위 내에 있을 때만 메인 로직이 실행되도록 보장합니다.

IF도 이제 삼항으로 대체되었습니다. 더 이상 마지막에 "알 수 없음"을 기본값으로 설정할 필요가 없기 때문입니다.

4. If-Else를 사전으로 변환 — If-Else를 완전히 피하세요

일부 조건에 따라 선택하는 일부 작업을 수행해야 한다고 가정하면 나중에 더 많은 작업을 추가해야 한다는 것을 알고 있습니다.

어떤 사람들은 시도되고 테스트된 If-Else를 사용하는 것을 선호할 수도 있습니다. 새 작업을 추가하는 경우 다른 작업을 추가하면 됩니다. 매우 간단합니다. 그러나 이 접근 방식은 유지 관리 측면에서 좋은 설계가 아닙니다.

나중에 새로운 연산을 추가해야 한다는 것을 알고 If-Else를 사전으로 리팩터링할 수 있습니다.

가독성이 대폭 향상되어 코드를 더욱 쉽게 추론할 수 있습니다.

사전은 설명 목적으로만 메소드 내부에 배치됩니다. 다른 곳에서 제공하고 싶을 수도 있습니다.

5. 애플리케이션 확장 — If-Else를 완전히 사용하지 마세요.

이것은 약간 더 발전된 예입니다.

If를 객체로 대체하여 완전히 제거해야 하는 시기를 알아보세요.

지원서의 일부 부분을 확장해야 하는 경우가 종종 있습니다. 주니어 개발자라면 추가 If-Else(예: else-if) 문을 추가하여 이 작업을 수행하고 싶을 수도 있습니다.

이 예시를 들어보세요. 여기서는 Order 인스턴스를 문자열로 표시해야 합니다. 첫째, JSON과 일반 텍스트라는 두 가지 문자열 표현만 있습니다. 이전에 언급한 대로 다른 항목을 쉽게 교체할 수 있다면 If-Else를 사용하는 것은 이 단계에서 큰 문제가 아닙니다.

애플리케이션의 이 부분을 확장해야 한다는 점을 알면 이러한 접근 방식은 절대 용납될 수 없습니다.

위 코드는 "열기/닫기" 원칙을 위반할 뿐만 아니라 잘 읽히지 않고 유지 관리 문제를 일으킬 수 있습니다.

올바른 접근 방식은 SOLID 원칙을 따르는 접근 방식입니다. 동적 유형 검색 프로세스(이 경우 전략 패턴)를 구현하여 이를 수행합니다.

이 지저분한 프로세스를 리팩토링하는 과정은 다음과 같습니다.

· 공통 인터페이스를 사용하여 각 분기를 별도의 전략 클래스로 추출합니다.

· 공통 인터페이스를 구현하는 모든 클래스를 동적으로 찾습니다.

· 어떤 전략을 실행할지 결정합니다. input

위 예제를 대체하는 코드는 다음과 같습니다. 예, 이것은 훨씬 더 많은 코드입니다. 유형 검색이 작동하는 방식을 이해해야 합니다. 그러나 애플리케이션을 동적으로 확장하는 것은 고급 주제입니다.

If-Else 예시를 대체할 정확한 부분만 보여드리겠습니다. 관련된 모든 개체를 보려면 이 요점을 확인하세요.

코드를 간단히 살펴보겠습니다.

호출자가 리팩토링에 대해 알 필요가 없으므로 메서드 서명은 변경되지 않습니다.

먼저, 공통 인터페이스 IOrderOutputStrategy를 구현하는 어셈블리의 모든 유형을 가져옵니다. 그런 다음 사전을 생성합니다. 포맷터의 displayName 이름은 키이고 유형은 값입니다.

그런 다음 사전에서 포맷터 유형을 선택하고 정책 개체를 인스턴스화해 보세요.

마지막으로 전략 개체의 ConvertOrderToString을 호출합니다.

위 내용은 우리 회사는 프로젝트에서 2,000개의 if-else를 어떻게 완전히 제거했나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!