시소당
It is important because it separates the switching logic from the details of
what happens.
액티비티(activity) 내용과 분기 로직을 분리한다. 보다 구체적으로 UML 다이어그램으로 표현해보면 다음과 같다.
애초의 내용이 왼쪽과 같다. 얼핏 간단해보이지만, A, B, C는 내용과 조건의 내용에 따라 실제 상황 변수를 대입해보면 상당히 복잡해질 것이다. 조건과 액티비티를 나누어보자.
모
든 경우에 대해서 이와 같이 나누어 표현한 것이 좋다고 할 수는 없다. 조건이나 A, B, C 액티비티가 간단하다면 나누지 않는
것이 좋을 수 있다. 반대로 조건이나 A, B, C가 복잡하다면 나누어서 표현하는 것이 이해하기에 좋다.
Refactoring에서 예로 든 것을 보자.
// before
if (date.before (SUMMER_START) || date.after(SUMMER_END))
charge = quantity * _winterRate + _winterServiceCharge;
else charge = quantity * _summerRate;
// after
if (notSummer(date))
charge = winterCharge(quantity);
else charge = summerCharge (quantity);
적용 방법(Mechanic)을 요약하면 다음과 같다:
if 안의 조건부와 then
에 해당하는 수행부, 그리고 else 이하의 수행부를 각각 메소드로 만들라는 것이다. 메소드로 만든다는 것은 하나의
액티비티로 응축시키는 것을 의미한다. 다른 코드와의
결합력(coupling)을 줄이면서 공통의 목적을 지니는 단위로
응집력(cohesion)을 강화시키는 기본적인 구조화 행위라고 할 수 있다.
위 코드를 그림(액티비티 다이어그램)으로 그려보면 이해가 더욱 쉬워진다.
이랬던 코드를 리팩토링하면 다음과 같이 된다.
이렇게 하여 얻게 되는 이점은 무엇인가?
코드의 의미가 더욱 분명해진다(make your intention clearer)는 가장 기본적이고도 근본적인 혜택을 제공한다.
참고:
-
Refactoring: Improving the Design of Existing Code 9장
출처 : http://younghoe.info/458