솔직히 당연한 소리다. 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보다 더 많이 보호받고 있는 것이 절대로 아니다.
'서적 정리 > Effective C++' 카테고리의 다른 글
26.변수 정의는 늦출 수 있는 데까지 늦추는 근성을 발휘하자 (0) | 2021.12.17 |
---|---|
25.예외를 던지지 않는 swap에 대한 지원도 생각해 보자 (0) | 2021.12.16 |
24.타입 변환이 모든 매개변수에 대해 적용되어야 한다면 비멤버 함수를 선언하자 (0) | 2021.12.15 |
23.멤버 함수보다는 비멤버 비프렌드 함수와 더 가까워지자. (0) | 2021.12.14 |
21.함수에서 객체를 반환해야 할 경우에 참조자를 반환하려고 들지 말자 (0) | 2021.12.14 |
20.'값에 의한 전달'보다는 '상수객체 참조자에 의한 전달' 방식을 택하는 편이 대개 낫다 (0) | 2021.12.14 |
19.클래스 설계는 타입 설계와 똑같이 취급하자 (0) | 2021.12.14 |
18.인터페이스 설계는 제대로 쓰기엔 쉽게, 엉터리로 쓰기엔 어렵게 하자 (0) | 2021.12.14 |
댓글