[Effective C++] 22. 데이터 멤버가 선언될 곳은 private 영역임을 명심하자

데이터 멤버를 private로 선언해야 하는 이유

1. 문법적 일관성

공개 인터페이스가 전부 함수뿐이라면, 클래스의 멤버에 접근할 때 괄호를 쓸지 말지 고민할 필요가 없다.

 

2. 세밀한 접근 제어

변수가 public이라면 읽기 및 쓰기 모든 것을 할 수 있지만, private로 만들면 읽기 전용, 쓰기 전용, 읽기 및 쓰기 전용 형식으로 구현할 수 있다.

즉, 접근 권한을 세밀하게 컨트롤 가능하다.

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; // 접근 불가
	int readOnly; // 읽기 전용
	int readWrite; // 읽기 쓰기 접근
	int writeOnly; // 쓰기 전용
};

 

3. 캡슐화

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

즉, 데이터 멤버를 캡슐화하면 구현상의 융통성을 전부 누릴 수 있고 이를 통해 데이터 멤버를 읽거나 쓸 때 다른 객체에 알림 메시지를 보내거나 클래스의 불변성 및 사전 조건과 사후 조건을 검증하고 스레딩 환경에서 동기화하기 등등을 간편하게 할 수 있다. (C#, Delphi의 property와 같다.)

 

public과 protected

실질적인 측면에서 캡슐화되지 않았다는 것은 바꿀 수 없다는 의미를 가지고 있다.

왜냐하면 여러 외부 클래스에서 이 데이터를 사용 중인 경우였지만, 데이터를 삭제할 일이 생긴다면 고칠 것이 많을 것이기 때문이다.

그리고 C++세상에서 public이란 '캡슐화되지 않았다'는 뜻이고 이는 protected도 동일하다.

 

요약

• 데이터 멤버는 private 멤버로 선언하자. 이를 통해 클래스 제작자는 문법적으로 일관성 있는 데이터 접근 통로를 제공할 수 있고, 필요에 따라서는 세밀한 접근 제어도 가능하며, 클래스의 불변 속성을 강화할 수 있을 뿐 아니라, 내부 구현의 융통성도 발휘할 수 있다.
• protected는 public보다 더 많이 보호받고 있는 것이 아니다.