타입 코드 처리하기

간단한 if 문 리팩터링

1. if 문에서 else를 사용하지 말 것

• 프로그램에서 이해하지 못하는 타입인지를 검사하지 않는 한 if문에서 else를 사용하지 않는다.

if-else를 사용하면 코드에서 결정이 내려지는 지점을 고정하게 된다. 그럴 경우 if-else가 있는 위치 이후에서는 다른 변형을 도입할 수 없기 때문에 코드의 유연성이 떨어진다.

• 독립된 if 문은 검사(check)로 간주하고, if-else 문은 의사결정(decision)으로 간주한다.

해당 규칙은 스멜로 인식되는 이른 바인딩(early binding)과 관련이 있다. 프로그램을 컴파일할 때 if-else 같은 의사결정 동작은 컴파일 시 처리되어 애플리케이션에 고정되며 재컴파일 없이는 수정할 수 없다.

이것의 반대는 코드가 실행되는 순간에 동작이 결정되는 늦은 바인딩(late binding)이다.

이른 바인딩은 if 문을 수정해야 변경할 수 있기 때문에 추가에 의한 변경을 방해한다.

before refcatoring

after rafactoring

• 다음에서 if-else를 제거하는 첫 번째 단계는 enum을 interface로 바꾸는 것이다. 그런다면 값들은 클래스로 바뀌게 되고, 값이 객체가 되기 때문에 if 구문 내의 코드를 각 클래스의 메서드로 옮길 수 있다.

with enum

interface

• 4개의 열거 값에 해당하는 4개의 클래스를 만든다. 클래스에 해당하는 메서드를 제외한 모든 메서드는 false를 반환시킨다.

make individual class

• 매개변수의 타입을 Input에서 Input2로 변경하고 일치 여부 검사를 새로운 메서드로 대체한다.

change type to interface

2. 클래스로 타입 코드 대체

해당 리팩터링 패턴은 enum을 인터페이스로 변환하고 enum의 값들은 클래스가 된다. 그렇게 하면 각 값에 속성을 추가하고 해당 특정 값과 관련된 기능을 특성에 맞게 만들 수 있다.

• 열거형의 값을 클래스로 변환할 때는 다른 열거 값을 고려하지 않고 해당 값과 관련된 기능을 그룹화 할 수 있다.
• 인터페이스를 구현한 새로운 클래스를 추가하는 것은 해당 클래스에서 메서드의 구현이 필요할 뿐, 새로운 클래스를 사용하기 전까지는 다른 코드를 수정하지 않아도 된다.

다음은 정해진 상수를 참조하지 않고 숫자를 사용했을 수 있기 때문에 int의 경우 타입 코드의 사용을 추적하는 것이 까다롭다. 즉, 타입 코드를 볼 때는 항상 즉시 열거형으로 변환한다.

use enum

• 모든 값에 대한 메서드를 갖는 것도 스멜이기 때문에 이것은 하나의 스멜을 다른 스멜로 대체한 것이다. 하지만 enum 값들은 밀접하게 연결되어 있는 반면, 메서드는 하나씩 처리할 수 있다.

3. 클래스로 코드 이관하기

• 해당 패턴은 기능을 클래스로 옮기기 때문에 클래스로 타입 코드 대체 패턴의 연장선에 있다.
• 결과적으로 if 구문이 제거되고 기능이 데이터에 더 가까이 이동한다.

before refactoring

인터페이스에 새로운 메서드를 만든다.

소스 함수를 복사하여 모든 클래스에 붙여 넣는다.

모든 클래스에서 새로운 메서드를 점검하여 수정한다.

메서드명을 적절하게 변경한다.

원래 함수의 본문을 새로운 메서드에 대한 호출로 바꾼다.

after refactoring

4. 불필요한 메서드 인라인화

• 프로그램에서 더 이상 가독성에 도움이 되지 않는 메서드를 제거한다.
• 흔히 메서드가 한 줄만 있는 경우 이 작업을 수행한다.
• 메서드가 인라인화하기에 너무 복잡하지 않은지 여부를 살핀다.