소프트웨어 개발에서 많은 부분이 indirection을 통해 해결됩니다. 그런데 때로는 indirection을 지나치게 남용해서, 프로그래밍을 더 복잡하게 할 때가 많습니다.
이렇게 indirection이 불필요하게 등장하는 주된 이유는, 프로그래머가 상황을 미리 대비하려고 하거나 좀 더 우아한 설계를 추구하기 때문입니다. 지금 할 수 있는 일만 잘 할 수 있게 코드를 최소한으로 짜 놓으면, 군더더기 indirection 코드는 생기지 않습니다.
간단한 예를 들어 보겠습니다. A 클래스가 B 클래스의 함수를 호출하는데, 호출 전에 B의 정보에 따라 어떤 처리를 해야 할 때가 가끔 있습니다. 그 처리를 A에서 직접 하는 게 맘에 들지 않는 프로그래머라면, A와 B 사이에 B의 관리자 역할을 하는 C 클래스를 만들어 A가 C를 거쳐 B에 명령을 내리려고 할 것입니다. 즉 퍼사드 패턴(facade pattern)을 도입하는 것입니다. 그러나 C가 실제로 하는 일이 거의 없다면, C는 단지 명령을 전달하는 역할을 할 뿐이고 B에 기능을 추가할 때마다 C도 고쳐야 하는 불편함만 따릅니다. 이럴 때엔 그냥 A에서 C의 역할을 하는 게 코드 양을 줄일 수 있습니다.
문제는 가능한 한 쉽게 해결해야 합니다. 따라서 indirection은 꼭 필요할 때만 사용해야 합니다.
이렇게 indirection이 불필요하게 등장하는 주된 이유는, 프로그래머가 상황을 미리 대비하려고 하거나 좀 더 우아한 설계를 추구하기 때문입니다. 지금 할 수 있는 일만 잘 할 수 있게 코드를 최소한으로 짜 놓으면, 군더더기 indirection 코드는 생기지 않습니다.
간단한 예를 들어 보겠습니다. A 클래스가 B 클래스의 함수를 호출하는데, 호출 전에 B의 정보에 따라 어떤 처리를 해야 할 때가 가끔 있습니다. 그 처리를 A에서 직접 하는 게 맘에 들지 않는 프로그래머라면, A와 B 사이에 B의 관리자 역할을 하는 C 클래스를 만들어 A가 C를 거쳐 B에 명령을 내리려고 할 것입니다. 즉 퍼사드 패턴(facade pattern)을 도입하는 것입니다. 그러나 C가 실제로 하는 일이 거의 없다면, C는 단지 명령을 전달하는 역할을 할 뿐이고 B에 기능을 추가할 때마다 C도 고쳐야 하는 불편함만 따릅니다. 이럴 때엔 그냥 A에서 C의 역할을 하는 게 코드 양을 줄일 수 있습니다.
문제는 가능한 한 쉽게 해결해야 합니다. 따라서 indirection은 꼭 필요할 때만 사용해야 합니다.
댓글을 달아 주세요
c라는 클래스 위에 d라는걸 또 얻어서 d->c를 호출하고 c에서 b를 호출하는 방식으로까지 발전하는 경우도 있던데...
그렇게 하는 게 더 낫다면 그래야겠죠. 아니라면 뭔가 잘못된 거지만요.