27-2-라.프렌드의 특성

프렌드 지정은 몇 가지 특성을 가지고 있는데 가급적이면 명시적으로 선언되지 않은 대상에 대해서는 특권을 주지 않는 성질이 있다. 코드 작성의 편의를 위해 예외적으로 프렌드라는 것을 도입했지만 그 부작용을 최소화하기 위해 마련된 규칙들이며 생각해 보면 아주 상식적인 것들이다.

프렌드 지정은 단방향이며 명시적으로 지정한 대상만 프렌드가 된다. A가 B를 프렌드로 선언했다고 하더라도 B가 A를 프렌드로 선언하지 않으면 A는 B의 프렌드가 아니다. 그래서 B는 A의 모든 멤버를 읽을 수 있지만 A는 그렇지 못하다.

다소 야박해 보이지만 사실 인간 관계에도 이런 예는 있다. 표준 위원들 사이에 friend라는 키워드가 실제 뜻인 "친구"와 정확하게 같지 않으므로 직관적이지 못하고 부적절하다는 지적이 있었다는 것은 참 재미있는 얘기다. 만약 A와 B가 서로 프렌드가 되려면 양쪽 모두 상대방을 프렌드로 지정해야 하며 이런 관계를 상호 프렌드라고 한다.

양쪽이 서로를 프렌드로 등록했으므로 A와 B는 서로의 멤버를 자유롭게 읽을 수 있다.

프렌드 지정은 전이되지 않으며 친구의 친구 관계는 인정하지 않는다. A, B, C 세 개의 클래스가 있을 때 이 관계를 그림으로 나타내 보면 다음과 같다.

A는 B를 프렌드 선언했고 B는 C를 프렌드 선언했다. 그래서 B는 A를 마음대로 액세스할 수 있으며 C도 B를 마음대로 액세스할 수 있다. 그러나 C는 A의 숨겨진 멤버를 액세스할 수 없다. C가 A의 프렌드가 되려면 A가 C를 프렌드로 지정해야 한다. 프렌드 함수의 경우도 마찬가지 규칙이 적용된다. func 함수가 A의 프렌드이고 B가 A를 프렌드로 지정한다고 해서 func 함수가 B를 액세스할 수 있는 것은 아니다. 프렌드 지정은 항상 허가하는 쪽에서 명시적으로 해야 한다.

복수의 대상에 대해 동시에 프렌드 지정을 할 수 있지만 한 번에 하나씩만 가능하다. A가 B, C를 동시에 프렌드로 지정하고 싶을 때 다음처럼 해야 한다.

class A

{

friend class B;

firend class C;

....

friend class B, C; 이런 문법은 허용되지 않는다는 간단한 얘기다. 프렌드 지정은 흔하지 않기 때문에 한 번에 하나씩 해도 별로 불편하지 않다.

프렌드 관계는 상속되지 않는다. A가 B를 프렌드로 지정하면 B는 A를 액세스할 수 있다. 그러나 B로부터 파생된 D는 A의 프렌드가 아니므로 A를 마음대로 액세스할 수 없다. 친구의 자식은 친구가 아니다.

그러나 D가 상속받은 B의 멤버 함수는 B 클래스의 소속이라고 볼 수 있으므로 여전히 A를 액세스할 수 있다.

프렌드는 OOP의 정보 은폐 원칙에 대한 일종의 예외이다. 숨겨 놓은 정보를 읽기 위해 일일이 액세스 함수를 경유하는 것이 너무 불편하고 때로는 외부 함수가 내부 멤버를 액세스해야 하는 불가피한 경우가 있어 프렌드가 반드시 필요하지만 너무 빈번하게 사용하는 것은 좋지 않다. 프렌드가 아니면 문제를 해결할 수 없는 경우에 한해서 조심 조심 사용해야 한다.

어떻게 생각하면 프렌드는 은폐된 정보의 기밀성을 완전히 무시해 버리므로 무척 위험한 장치처럼 생각될 수도 있다. 그러나 개발자의 명시적인 지정에 의해서만 예외를 인정하며 그것도 클래스의 선언부에서만 지정할 수 있고 클래스 외부에서는 지정할 수 없으므로 위험하지는 않다. 외부의 클래스나 함수가 임의로 프렌드 선언을 하고 마음대로 읽고 쓸 수는 없다는 얘기다. 프렌드 지정에 의해 공개되는 범위는 지정한 클래스나 함수에 국한되므로 전면적인 공개와는 성질이 다르다.