본문 바로가기
서적 정리/Effective C++

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

by 민돌이2 2021. 12. 14.

솔직히 당연한 소리다. private에 선언함 으로써 캡슐화를 하기 때문이고 무엇보다 멤버 데이터를 누구나 손댈 수 있다면 프로그램에 무슨일이 생길지 어느 누구도 예측할 수가 없다.

 

만약 어떤 클래스의 공개 인터페이스에 있는 것들이 전부 함수뿐이라면, 그 클래스의 멤버에 접근하고 싶을 때 괄호를 무조건 붙여야 할 것이다. 무조건 괄호를 붙임으로써 문법적 일관성이 지켜진다.

어떤 데이터 멤버를 public으로 선언했다면 모두가 이 데이터에 대해 읽기 및 쓰기 접근권한을 갖게 되지만, 이 값을 읽고 쓰는 함수가 있으면, 접근 불가, 읽기 전용, 읽기 쓰기 접근을 구현할 수 있다.

내가 많이 쓰는 방법이다.

class AccessLevels { public: int GetReadWrite() const { return readWrite; } void SetReadWrite(int value) { readWrite = value; } private: int readWrite; };

 

데이터 멤버를 함수 인터페이스 뒤에 감추게 되면 구현상의 융통성을 전부 누릴 수 있다.

데이터 멤버를 읽거나 쓸 때 다른 객체에 알림 메시지를 보낸다든지, 클래스의 불변속성 및 사전조건(precondition), 사후조건(postcondition)을 검증한다든지, 스레딩 환경에서 동기화를 건다든지 하는것이 가능해진다. 

 

얼핏 protected 데이터 멤버면 다른 객체가 접근 불가하니 private랑 같지 않을까? 라는 생각을 갖을 수있다. 어떤 것이 바뀌면 깨질 가능성을 가진 코드가 늘어날 때 캡슐화의 강도는 그에 반비례해서 작아진다.

어떤 클래스에 public 데이터 멤버가 있고, 이것을 제거한다고 생각해보자. 제거된 데이터 멤버가 사용되는 수많은 코드들이 박살날 것이다. protected 또한 마찬가지다. 삭제된 protected 데이터 멤버의 파생 클래스는 전부 박살날 것이다.

 

이것만은 잊지 말자

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

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

728x90

댓글