friend 검사창

기준을 묻는다

public API만으로 구현할 수 있다면 friend 없이도 객체의 계약이 유지된다.

권한 범위 축소

클래스 전체 friend보다 특정 free function 하나에만 접근권을 준다.

표현 변경을 상상한다

private 멤버 이름이 바뀔 때 friend 코드도 함께 깨지는 비용을 설계에 반영한다.

연산자

왼쪽 타입이 외부 ostream 출력처럼 왼쪽 피연산자를 멤버로 만들 수 없을 때 friend가 자연스럽다.

읽기만 필요한지 확인한다.

테스트

마지막 수단 테스트 전용 friend는 private 구현을 고정시키는 부작용이 크다.

행동 검증을 먼저 시도한다.

직렬화

포맷 결합 내부 값을 그대로 파일 형식으로 노출하면 버전 변경이 어려워진다.

DTO 변환을 사이에 둘 수 있다.

상호 클래스

강한 결합 두 클래스가 서로 friend라면 책임 분리가 흐려진 신호일 수 있다.

공유 객체를 별도로 빼 본다.

권한 최소화 · 표현 의존 · 대안 점검

권한 최소화 friend 대상이 함수 하나인지, 불필요하게 클래스 전체인지 확인한다.

표현 의존 private 필드 이름이나 자료구조 변경이 friend 사용자까지 깨뜨리는가.

대안 const getter, 방문자, 변환 함수로 같은 목적을 더 낮은 결합으로 이룰 수 있는가.

제한된 출력 권한

class Point {
public:
    Point(int x, int y) : x_(x), y_(y) {}
    friend std::ostream& operator<<(std::ostream& os, const Point& p);
private:
    int x_, y_;
};