규칙 2: else 예약어 금지
모든 프로그래머는 if/else 구문을 이해한다. 이 구문은 거의 모든 프로그래밍 언어에 들어 있고, 간단한 조건 논리는 누구나 쉽게 이해한다. 거의 모든 프로그래머는 따라가기 불가능할 정도로 지저분한 중첩 조건문이나 몇 페이지씩 되는 case 문을 본 적이 있을 것이다. 더욱이 리팩토링보다는 그냥 기존 조건문에 분기를 하나 더 치기가 무척 쉽다는 점이다. 조건문은 또한 곧잘 코드 중복의 원흉이기도 하다. 예를 들어 아래 status 플래그는 자주 이런 문제에 빠진다.
public static void endMe() {
if (status == DONE) {
doSomething();
} else {
// 다른 코드
}
}
else를 빼고 코드를 다시 짜는 데는 몇 가지 방법이 있다. 간단하게, 이렇게 짠다.
public static void endMe() {
if (status == DONE) {
doSomething();
return ;
}
// 다른 코드
}
public static Node head() {
if (isAdvancing()) { return first; }
else { return last; }
}
public static Node head() {
return isAdvancing() ? first : last;
}
위에서 4줄이 한 단어가 늘면서 1줄로 줄어버렸다. return 문을 일찍 쓰는 것을 너무 많이 하면 간결함을 저해하기 쉽다는 점을 간과해서는 안 된다. 디자인 패턴[GHJV95] 책의 Strategy 패턴을 보면 상태 인라인(status inline)에 분기를 막기 위해 다형성(polymorphism)을 쓰는 예제가 나온다. 상태에 대한 분기가 몇 군데 걸쳐 중복돼 있을 때 Strategy 패턴은 특히 유용하다.
소트웍스 앤솔러지: 소프트웨어 기술과 혁신에 관한 에세이
객체지향 언어는 다형성이라는 강력한 도구를 통해 복잡한 조건문을 처리할 수 있다. 간단한 경우라면 보호절(guard clause)과 조기 반환(early return)으로 대체 가능하다. 다형성을 채택한 설계는 읽고 유지하기 쉬우며 더욱 분명히 코드의 의도를 표현하기에 이른다. 그렇게 하기가 늘 쉽지는 않으며, 특히 뒷주머니에 else가 있을 때 특히 그렇다. 그래서 이 훈련의 일환으로 else 사용은 금지다. 널 객체 패턴(Null Object Pattern)을 시도해 보면 특정 상황에서 도움이 될 것이다. 다른 방법들도 마찬가지로 else를 제거하는 데 도움될 수 있다.
—-
이 글은 『소트웍스 앤솔러지』의 내용 중 일부를 발췌한 것입니다. 세 번째 객체지향 훈련 지침인 “원시값과 문자열의 포장”도 조만간 공개됩니다.
