CH06 : 조건분기

CHAPTER 6 : 조건분기

범위 : 86p ~ 132p
단계 : 실전
제목 : 조건분기, 미궁처럼 복잡한 분기 처리를 무너뜨리는 방법
내용 : 복잡한 조건 분기를 정리하고 구조화하는 방법을 다룹니다.

INTRO

이 장에서 If 조건문과 switch 조건문 등 조건 분기와 관련된 악마 퇴치법을 소개하곘습니다.

조건 분기는 조건에 따라 처리 내용을 전환하는데 사용되는 프로그래밍의 기본 제어 구조입니다. 조건 분기를 사용하면 복잡한 판단을 빠르고 정확하게 할 수 있습니다.

• 그런데 조건 분기를 대충 다루면, 악마가 되어 개발자들을 괴롭힙니다. 조건이 복잡해면 코드의 동작을 이해하기 힘듭니다.

이해하기 어려운 코드는 디버그하고 사양을 변경하는데 시간이 오래 걸립니다. 분기 로직을 정확하게 이해하지 못하고 사양을 변경하면, 버그가 생길 수 있습니다.

조건 분기에는 어떤 악마가 숨어있을까요? 차근차근 살펴봅시다.

6.1 조건 분기가 중첩되어 낮아지는 가독성

(중략) 여러개의 조건을 판정하기 위해 if 조건문 내부에 if 조건문, 그리고 내부에 또 if 조건문을 넣는 식으로 if 조건문을 중첩했습니다.

중첩을 하면 어떤 문제가 생길까요 ?

• 코드의 가독성이 크게 떨어지는 문제가 있습니다.
• 어디부터 어디까지 if 조건문의 처리 블록인지 이해하기 힘듭니다. 따라서 어떤 조건을 만족할 떄 어떤 로직이 처리되는지 이해하는 것만으로도 많은 시간을 낭비합니다.
• 코드를 읽을 때마다 낭비가 생기고, 코드를 읽는 사람 모두가 이런 일을 겪는다. 이처럼 가독성이 나쁜 코드는 팀 전체의 개발 생산성을 저하 시킵니다.

사양 변경은 더 힘듭니다.

• 코드가 복잡하고 길면 로직을 정확하게 읽고 이해하기 어렵습니다. 그리고 충분히 이해하지 못한 상태에서 로직을 변경하면, 버그가 쉽게 숨어듭니다.

6.1.1 조기 리턴으로 중첩 제거하기

중첩 악마를 퇴치하는 방법 중 하나로 Early Return(조기 리턴)이 있습니다

• Early Return은 조건을 만족하지 않은 경우 곧 바로 리턴하는 방법입니다.
• Early Return하는 형태로 변경하려면, 원래 조건을 반전해야 한다. 즉 ‘살아 있는가’ 를 ‘죽은 상태인가?’로 변경해야 합니다.

Early Return의 또 다른 장점

• 조건 로직과 실행 로직을 분리할 수 있다.

6.1.2 가독성을 낮추는 else 구문도 조기 리턴으로 해결하기

else 구문도 가독성을 나쁘게 하는 원인 중 하나이다. 이 또한 Early Return으로 해결할 수 있다.

6.2 switch 조건문 중복

6.2.1 switch 조건문을 아숑해서 코드 작성하기

• N / A

  6.2.2 같은 형태의 switch 조건문이 여러 개 사용되기 시작

• N / A

  6.2.3 요구 사항 변경 시 수정 누락 (case 구문 추가 누락)

• N / A

  6.2.4 폭발적으로 늘어나는 switch 조건문 중복

• N / A

  6.2.5 조건 분기 모으기

• N / A

  6.2.6 인터페이스로 switch 조건문 중복 해소하기

• N / A

  6.2.7 인터페이스를 switch 조건문 중복에 응용하기 (전략패턴)

• N / A

  종류별로 다르게 처리해야하는 기능을 인터페이스의 메서드러 정의하기

• N / A

  인터페이스의 이름을 결정하는 방법 : “어떤 부류에 속하는가?”

• N / A

  종류별로 클래스 만들기

• N / A

  각각의 클래스에 인터페이스 구현하기

• N / A

  switch 조건문이 아니라, Map으로 변경하기

• N / A

  메서드를 구현하지 않으면 오류로 인식하게 만들기

• N / A

  값 객체화하기

• N / A

  6.3 조건 분기 중복과 중첩

  인터페이스는 switch 조건문의 중복을 제거할 수 있을 뿐 만이 아니라, 다중 중첩된 복잡한 분기를 제거하는 데 활용할 수 있습니다.

6.3.1 정책 패턴으로 조건 집약하기

Policy Pattern, 정책 패턴

• 조건을 부품처럼 만들고, 부품으로 만든 조건을 조합해서 사용하는 패턴이다.

6.4 자료형 확인에 조건 분기 사용하지 않기

인터페이스는 조건 분기를 제거할 때 활용할 수 있다고 설명했습니다. 그런데 인터페이스를 사용해도 조건 분기가 줄어들지 않는 경우가 있습니다. (p124)

리스코프 치환 원칙

• 리스코프 치환 원칙은 클래스의 기반 자료형과 하위 자료형 사이에 성립하는 규칙입니다. 간단한게 설명하면 ‘기반 자료형을 하위 자료형으로 변경해도, 코드는 문제 없이 동작해야 한다’라는 의미입니다.
  • 여기서 기반 자료형은 ‘인터페이스를’를 의미하며, 하위 자료형은 인터페이스를 구현한 클래스를 의미합니다.
• 리스코프 치환 원칙을 위반하면 자료형 판정을 위한 조건 분기 코드가 점점 많아져서, 유지 보수하기 어려운 코드가 되어버립니다. 인터페이스의 의미를 충분히 이해하지 못하고 사용하면 이와 같은 로직이 자주 만들어집니다.

6.5 인터페이스 사용 능력이 중급으로 올라가는 첫 걸음

인터페이스를 잘 사용하는지가 곧 설계 능력의 전환점이라고 할 수 있습니다.

조건 분기를 써야 하는 상황에는 일단 인터페이스 설계를 떠올리자! 를 머릿속에 새겨 두기만 해도 조건 분기 처리를 대하는 방식 자체가 달라질 것 입니다.

6.6 플래그 매개변수

메서드의 기능을 전환하는 boolean 자료형의 매개 변수를 플래그 매개변수 라고 부릅니다.

• 플래그 매개변수를 받는 메서드는 어떤 일을 하는지 예측하기 굉장히 힘듭니다. 예측을 하기 위해서는 반드시 메서드 내부 로직을 확인해야 하므로, 가독성이 낮아지며 개발 생산성이 저하됩니다.

6.6.1 메서드 분리하기

플래그 매개변수를 받는 메서드는 내부적으로 여러 기능을 수행하고 있으며, 플래그를 사용해서 이를 전환하는 구조를 갖습니다. 메서드는 하나의 기능만 하도록 설계하는 것이 좋습니다. 따라서 플래그 매개변수를 받는 메서드는 기능별로 분리하는 것이 좋습니다.

*셀렉터 매개변수

• 기능 전환을 하기 위한 매개변수

6.6.2 전환은 전략 패턴으로 구현하기

• 플래그 매개변수가 아니라 전략 패턴을 사용하세요.