[객체지향 생활 체조] 규칙 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;
   }
   if (status != DONE) {
      // 다른 코드
      return;
   }
}

또 다른 예시로는 아래 코드처럼 else 예약어를 빼고 삼항연산자를 이용해서 처리하는 방법도 있다.

public static Node head() {
   if (isAdvancing()) { return first; }
   else { return last; }
}

public static Node head() {
   return isAdvancing() ? first : last;
}

그러나 early return(조기 반환)을 너무 많이 하면 간결함을 저해하기 쉽다는 점을 주의해야 한다.

디자인 패턴[GHJV95] 책의 Strategy 패턴을 보면 상태 인라인(status inline)에 분기를 막기 위해 다형성(polymorphism)을 쓰는 예제가 나온다. 상태에 대한 분기가 몇 군데 걸쳐 중복돼 있을 때 Strategy 패턴은 특히 유용하다.

객체지향 언어는 다형성이라는 강력한 도구를 통해 복잡한 조건문을 처리할 수 있다. 간단한 경우라면 보호절(guard clause)과 조기 반환(early return)으로 대체 가능하다. 다형성을 채택한 설계는 읽고 유지하기 쉬우며 더욱 분명히 코드의 의도를 표현하기에 이른다. 그렇게 하기가 늘 쉽지는 않으며, 특히 뒷주머니에 else가 있을 때 특히 그렇다. 그래서 이 훈련의 일환으로 else 사용은 금지다. 널 객체 패턴(Null Object Pattern)을 시도해 보면 특정 상황에서 도움이 될 것이다. 다른 방법들도 마찬가지로 else를 제거하는 데 도움될 수 있다.

---

코딩할 때 빼놓을 수 없는 것이 if-else 구문인데, else를 금지하라니 처음엔 조금 와닿지 않기도 했다. 좀 더 서칭해서 상세 예제들도 보고 하니 조금은 이해가 되는 것이 어떤 메소드 안에 if-else로 처리되어 있으면 그 메소드의 역할이  불분명해질 수도 있기 때문에 바로 return으로 결과를 주는 식으로 처리하는 것이 해당 메소드의 역할이 확실해지는 것 같긴 하다. 

[참고 및 출처]

developerfarm.wordpress.com/2012/01/27/object_calisthenics_3/