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

데이터 멤버는 전부 private로 놔야 한다. 그래야만 문법적 일관성과 캡슐화가 제대로 되기 때문이다. 예를 들어보자 public는 모든 곳에서 접근할 수 있다. 만약 public 멤버 데이터를 누군가가 참조했으면 나중에 고칠 때 그 참조했던 것과 참조한 것을 참조한 것을 모두 고쳐야 한다. 그리고 protected도 마찬가지이다. protected는 상송된 관계 모드가 참조 가능하다 그렇다면 이것도 똑같이 수정 시에 모두 수정하여야 한다.

 

이제 private에 대해서 말하겠다. 아까 무법의 일관성을 지키려면 private를 사용하라고 한 것 기억하는가? 난 이게 확 와 닿지 않았다. 하지만 정교한 제어가 가능하다고 하니까 그때서야 느낌이 "파밧!" 왔다. 는 구라고 소스코드 보고  아 "그런갑다~" 했다. (천재였으면 좋겠다~)

 

class AccessLevels 
{
private:
	int noAccess;
	int readOnly;			//읽기만 가능
	int readWrite;			//읽기 쓰기가능
	int writeOnly;			//쓰기만 가능
public:

	int getReadOnly() const { return readOnly; }			//읽기만 가능	

	int setReadWrite(int value) { readWrite = value; }		//읽기 쓰기
	int getReadWrite() const { return readWrite; }			//가능

	void setWriteOnly(int value) { writeOnly = value; }		//쓰기만 가능

};

이렇게 함수로 만들어서 계산식으로 이요하든 뭘 하든 값을 세밀하게 제공해줄 수 있다. 그리고 또 한가지 아까 말했던 캡슐화이다. 데이터 멤버를 뒤에 숨겨놓고 함수를 통해서만 멤버에 접근할 수 있으면 데이터 멤버로 게 산식으로 대체할 수도 있고, 불변 속성, 사후 조건 검증, 스래딩 환경에서 동기화를 거는 등 도 가능하다.

private으로 해놓으면 불변속성을 유지하는 데에 소홀해질 수가 없다고 한다. 이유는 멤버에 접근하는 통로는 함수 밖에 없으니까 라고.....

 

이것만은 잊지 말자!

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

2. protected는 public보다 더 많이 '보호'받고 있는 것이 절대로 아니다.(걍 똑같다 라고보면된다)