- Dennis DeBruler-
비슷한 말로 정보공학의 모든 문제는 별도의 레이어인 인디렉션으로 해결된다 -Butler W. Lampson-
라는 말이 있다.
※여기서 인디렉션은 추상화 혹은 간접참조라는 개념으로 통용되는 것 같다.
소프트웨어 엔지니어들은 인디렉션을 대단히 좋아하기 때문에 대부분의 리팩토링이 프로그램에 더 많은
인디렉션을 도입한다는 것을 알게 되더라도 별로 놀랍지 않을 것이다. 리팩토링은 큰 객체를 여러 개의
작은 객체로 쪼개고, 긴 메소드를 여러개의 작은 메소드로 나누는 경향이 있다.
그러나 인디렉션은 양날의 칼과 같다. 하나를 둘로 나누게 되면 그만큼 관리해야 하는 것도 많아지게 된다.
또한 한 객체가 다른 객체에 위임하고 그 객체는 다른 객체에 위임하고... 이런 식이라면 프로그램을 이해하기
어렵게 만들 수도 있다. 따라서 인디렉션을 최소화하고 싶을 것이다.
너무 서두르지 말기를... 인디렉션은 그만큼 충분한 가치가 있다. 여기에 그 예가 있다.
- 로직공유 예를 들면, 다른 두 곳에서 호출되는 서브메소드나, 모든 서브클래스에서 공유되는
수퍼클래스의 메소드에 있다. - 의도와 구현을 분리하기 위한 설명 클래스의 이름과 메소드의 이름을 정하는 시점이 코드의
의도를 설명할 기회이다. 클래스와 메소드의 내부는 그 의도를 어떻게 구현했느지를 설명한다.
만약 내부 역시 의도의 관점에서 작성되었다면, 그 구조에 대한 중요한 정보의 대부분을 잘 전달
하도록 코드를 작성할 수 있다. - 변경의 격리 하나의 객체가 다른 두 곳에서 사용된다. 나는 두 경우 중 하나의 동작을 바꾸고 싶다.
내가 그 객체를 직접 수정하게 되면 두 경우 모두 바뀔 위험이 있다. 따라서 나는 먼저 서브클래스를
만들고, 바꾸려고 하는 곳에서 이 객체를 참조하게 한다. 이제 나는 다른 곳에 의도하지 않은 변화가
생길 위험 없이 서브 클래스를 수정한다. - 조건 로직의 부호화 객체는 다형성 메시지라는 훌륭한 메커니즘을 가지고 있어 조건 로직을
융통성 있고 명확하게 표현할 수 있다. 조건문을 다형성 메시지를 사용하도록 바꾸고 중복을
줄일 수 있고, 동시에 융통성을 늘릴 수 있다.
여기 리팩토링 게임이 있다. 시스템의 현재 동작을 유지하면서, 어떻게 품질을 향상시키거나 또는 비용을
절감하여 시스템의 가치를 높일 수 있을까?
이 게임의 가장 일반적인 형태는 프로그램을 들여다 보는 것이다. 인디렉션으로 얻을 수 있는 이익을 얻지
못하고 있는 곳을 확인한다. 현재의 동작을 변경하지 않으면서 인디렉션을 넣는다. 이제 우리는 내일도 이
프로그램을 잘 이해할 수 있을 것이므로, 더 가치있는 프로그램이 되었다.
주의 깊은 사전 디자인(Upfront Design)과 대조해보자. 이론적인 디자인은 코드를 작성하기 전에 시스템에
모든 좋은 특성을 집어넣는 것이다. 그러면 코드는 단지 튼튼한 뼈대에 매달리기만 하면 된다. 이 프로세스
의 문제는 잘못생각하기가 너무 쉽다는 것이다.
리팩토링을 하면 완전히 잘못되는 위험에는 절대로 빠지지 않는다. 프로그램은 항상 처음에 동작하던 대로
동작한다. 게다가 코드에 귀중한 특성을 추가할 기호를 가지게 된다.
흔하지 않지만 여기 두 번째 리팩토링 게임이 있다. 존재할 가치가 없는 인디렉션을 찾아서 제거하는 것이다.
이것은 종종 어떤 목적을 지원하기 위해 사용됐지만 이제는 더이상 작업하지 않는 중간 메소드의 형태를
가진다. 또는 공유되거나 다형성이 필요하다고 예상했지만 실제로는 단 한곳에서만 사용되는 컴포넌트 일
수도 있다.
만약 기생하고 있는 인디렉션을 발견한다면 제거하라. 프로그램이 더가치있게 될것이다.
이는 프로그램의 위에서 나열한 네가지 특성중 하나 이상을 가져서가 아니라, 인디렉션을 적게 사용하면서
프로그램의 질은 같기 때문이다.
