항목 22 ] 데이터 멤버가 선언될 곳은 private 영역임을 명시하자.

데이터 멤버가 선언될 곳은 private 영역임을 명시하자.

데이터 멤버를 public에 선언할 경우 어디에서든지 누구나 데이터에 접근할수 있기 때문에,
읽기, 쓰기, 접근권한을 갖게 되지만, 이 값을 읽고 쓰는 함수가 있으면 접근 불가, 읽기 전용, 읽기 쓰기 접근을
여러분이 직접 구현할 수 있습니다. 심지어 쓰기 전용 접근도 필요하다면 구현 할 수 있습니다.

 

 

세밀한 통제

class AccessLevels 
{
public:
    int getReadOnly()const
    {
        return readOnly; 
    }
    void setReadWrite( int value )
    {
        readWrite = value; 
    }
    int getReadWrite()const
    {
        return readWrite; 
    }
    void setWriteOnly(int value)
    {
         writeOnly = value; 
    }
private:
    int noAccess;     // noAccess에 대해서는 접근 불가
    int readOnly;     // readOnly에 대해서는 읽기 전용 접근
    int readWrite;      // readWrite에 대해서는 읽기 쓰기 접근
    int writeOnly;    // writeOnly에 대해서는 쓰기 전용 접근
 
};

이렇게 세밀한 접근제어는 나름대로의 중요성을 갖고 있습니다.
어떤 식으로든 외부에 노출시키면 안 되는 데이터 멤버들이 꽤 많기 때문이죠.
사실 모든 데이터 멤버에 읽기 및 쓰기 함수를 달아 줄 일은 극히 드뭅니다.

함수를 통해서만 데이터 멤버에 접근할 수 있도록 구현해 두면, 데이터 멤버를 나중에 계산식으로 대체할 수도 있을 것이고, 사용자는 절대로 이 클래스를 넘볼 수 없을 것입니다.

 

그럼 Protected는?

protected 데이터 멤버의 경우도, 앞서 말한 사정과 비슷합니다. 문법적 일관성과 세밀한 접근 제어에 관한 이야기라면 public 데이터 멤버처럼 protected 데이터 멤버에도 그대로 적용할 수 있습니다.

어떤 클래스에 public 데이터 멤버가 있고, 이것을 제거한다고 가정합시다. 이 멤버에 매달려 있는 얼마나 많은 코드가 망가질까요? 이것을 사용하는 코드는 전부 무사하지 못할것입니다.

파악조차 힘들만큼 엄청 많겠지요.

이젠 protected데이터 멤버를 제거한다고 가정해 봅시다. 이번엔 코드가 얼마나 망가질까요?
이것을 사용하면 파생 클래스는 전부…

역시 파악조차 힘들만큼 많아질것입니다.
조금 가렸다고 가진게 아닙니다.

protected나 public이나 거기서 거기입니다.

 

결론

데이터 멤버는 private 멤버로 선언합시다.

이를통해 클래스 제작자는 문법적으로 일관성 있는 데이터 접근 통로를 제공할 수 있고,

필요에 따라서는 세밀한 접근 제어도 가능하며, 클래스의 불변속성을 강화할 수 있을뿐 아니라,

내부 구현의 융통성도 발휘할 수 있습니다.

protected는 public보다 더 많이 ‘보호’ 받고 있는 것이 절대로 아닙니다.