Dev 일기장

# 개요

리팩토링 9장, 조건문 간결화 읽고 간단 정리

각 카탈로그에서 설명하는 내용 중 중요하게 생각하는 부분 작성하고 내 생각도 덧붙임

코드 작성하다가 이 예시가 이거구나 싶을 때는 예시코드도 붙일 예정

# 조건문 간결화

객체 지향 프로그램은 절차 프로그램에 비해 조건에 따른 동작이 대체로 적은데, 이것은 조건에 따른 동작 대부분이 재정의를 통해 처리되기 때문이다.

재정의 방식이 좋은 이유는 호출 코드가 조건문 원리를 알 필요가 없어 조건문을 확장하기가 더 간편하기 때문이다.

Decompose Conditional (조건문 쪼개기)

복잡한 조건문이 있을 땐 각 부분을 메서드로 빼내자

조건을 검사하고 다양한 조건에 따라 다른 작업을 처리하는 코드를 작성하다 보면 금방 메서드가 길어진다. 메서드는 길어지기만 해도 알아보기 힘든데 조건문까지 많으면 더 심각하다.

• 6장의 메서드 추출 카탈로그에서 한 얘기와 비슷하다. 결국 메서드는 짧고 이해하기 쉬워야 하는데 조건문이 길면 이해하기 어렵다. 바로 적절한 이름을 가진 메서드로 추출하자.

Consolidate Conditional Expression (중복 조건식 통합)

여러 조건 검사식의 결과가 같을 땐 하나의 조건문으로 합친 후 메서드로 빼내자

조건문을 합쳐야 하는 이유는 두 가지이다.

1. 조건식을 합치면 여러 검사를 OR 연산자로 연결해서 하나의 검사 수행을 표현해서 무엇을 검사하는지 확실히 이해할 수 있다.
2. 이러한 조건식 통합을 실시하면 메서드 추출을 할 기반이 마련된다.

조건식이 독립적이고 하나의 검사로 인식되지 말아야 할 땐 이 기법을 사용하면 안된다. 그 코드는 이미 개발자의 의도에 맞기 때문이다.

• 나는 대체로 isValid같은 메서드를 만들 때 이런 고민을 많이한다. ||나 && 연산자를 이용하여 한 줄로 간단하게 표현하는게 좋을까? 아니면 각 하나의 조건이 valid/invalid를 명시하도록 하기 위해 조건절을 나누는게 좋을까?
• 근데 대체로 조건절을 나눠서 표현하는 경우가 많다. (그게 맞는지는 정확히 모르겠다)

Consolidate Duplicate Conditional Fragments (조건식의 공통 실행 코드 빼내기)

조건문의 모든 절에 같은 코드가 있을 땐 같은 부분을 조건문 밖으로 빼내자

• 조건문이 늘어나면 코드가 당연히 길어지는데 최대한 중복을 줄일 수 있는 부분은 줄이는 것이 중요하다고 생각한다.

Remove Control Flag (제어 플래그 제거)

논리 연산식의 제어 플래그 역할을 하는 변수가 있을 땐 그 변수를 break나 return문으로 바꾸자

제어 플래그는 유용함을 능가하는 단점이 있다. 제어 플래그로 인해 이탈점이 한 개가 되면 코드 안의 각종 특이한 플래그로 조건문이 복잡해진다.

• 플래그가 하나면 그러려니 하겠는데 여러 개인 경우 정말 복잡해진다. 거기다 break/continue/return 등으로 해당 조건이 탈출 조건이라는 것을 명시할 수 있어서 가독성 면에서도 더 좋다고 생각한다.

Replace Nested Conditional with Guard Claueses (여러 겹의 조건문을 감시 절로 전환)

메서드에 조건문이 있어서 정상적인 실행 경로를 파악하기 힘들 땐 모든 특수한 경우에 감시 절을 사용하자.

조건문은 두 가지 형태를 띤다

1. 어느 한 경로가 정상적인 동작의 일부인지 검사
2. 조건식 판별의 한 결과만 정상적인 동작을 나타내고 나머지는 비정상적인 동작을 나타냄

조건문은 다양한 의도가 있는데 그 의도는 코드에 반영되어 드러나야 한다.

1. 둘 다 정상 동작의 일부라면 if ~ else로 구성된 조건문을 사용하고
2. 조건문이 특이한 조건이라며 그 조건을 검사하여 조건이 true일 경우 반환하도록 한다.

Replace Conditional with Polymorphism (조건문을 재정의로 전환)

객체 타입에 따라 다른 기능을 실행하는 조건문이 있을 땐 조건문의 각 절을 하위 클래스의 재정의 메서드 안으로 옮기고 원본 메서드는 abstract 타입으로 수정하자.

재정의의 본질은 타입에 따라 기능이 달라지는 여러 객체가 있을 때 일일이 조건문을 작성하지 않아도 다형적으로 호출되게 할 수 있다는 것이다.

• 내 개인적인 생각인데 객체 지향 언어의 꽃이 이 부분이라고 생각한다. 이 기법을 잘 사용하면 코드 확장성도 유용해지고 하나의 클래스는 하나의 역할만 갖게 된다고 생각한다.

# 내 생각

사실상 조건문을 재정의로 전환하는것이 가장 중요하고 그만큼 어렵다고 생각한다. 이번에 프로젝트를 할 때 책을 보며 이 기법을 적용 해 보았는데 확실히 코드가 가독성도 좋아졌고 새 기능을 추가하기도 쉬워졌다는 생각이 들었다.