항목 22 : 데이터 멤버가 선언될 곳은 private 영역임을 명심하자
이번 항목에서는 데이터 멤버가 어째서 public이면 안 되는지에 대한 이유를 알아보고, public 데이터 멤버에 대한 모든 이야기가 protected 데이터 멤버에도 똑같이 적용되는 모습을 함께 확인하도록 하지요.
public 데이터 멤버는 왜 안 될까요?
우선 문법적 일관성이 이유가 되겠습니다.
데이터 멤버가 public이 아니라면, 사용자 쪽에서 어떤 객체를 접근할 수 있는 유일한 수단은 멤버 함수일 것입니다.
그렇다면 그 클래스의 멤버에 접근하고 싶을 때 그냥 함수를 쓰기만 하면 됩니다.
만일, 어떤 데이터 멤버를 public으로 내놨다면 모두가 이 멤버에 대해 읽기 및 쓰기 접근권한을 가지게 되지만, 이 값을 읽고 쓰는 함수가 있으면 접근 불가, 읽기 전용, 읽기 쓰기 접근을 여러분이 직접 구현할 수 있습니다. 심지어 쓰기 전용 접근도 필요하면 구현할 수 있습니다. 이렇게 세밀한 접근 제어는 나름대로의 중요성을 가지고 있습니다. 어떤 식으로든 외부에 노출시키면 안 되는 데이터 멤버들이 꽤 많기 때문이죠.
캡슐화의 이점도 있습니다.
함수를 통해서만 데이터 멤버에 접근할 수 있도록 구현해 두면, 데이터 멤버를 나중에 계산식으로 대체할 수도 있을 것이고, 사용자는 절대로 이 클래스를 바꿀수 없을 것 입니다.
데이터 멤버를 함수 인터페이스 뒤에 감추게 되면 구현상의 융통성을 전부 누릴 수 있습니다.
예를 들면, 데이터 멤버를 읽거나 쓸 때 다른 객체에 알림 메시지를 보낸다든지, 클래스의 불변속성 및 사전조건, 사후조건을 검증한다든지, 스레딩 환경에서 동기화를 건다든지 하는 일이죠.
C++ 세상에서 public이란 '캡슐화되지 않았다'는 뜻이며, 실질적인 측면에서 이야기할 때 '캡슐화되지 않았다'라는 말은 '바꿀 수 없다'라는 의미를 담고 있습니다.
protected 데이터 멤버의 경우도, 앞서 말한 사정과 비슷합니다.
캡슐화의 관점에서 쓸모 있는 접근 수준은 private(캡슐화 제공)와 private가 아닌 나머지(캡슐화 없음), 이렇게 둘뿐이라고 말할 수 있습니다.
꼭 잊지 말아야 할 것!
1. 데이터 멤버는 private 멤버로 선언합시다. 이를 통해 클래스 제작자는 문법적으로 일관성 있는 데이터 접근 통로를 제공할 수 있고, 필요에 따라서는 세밀한 접근 제어도 가능하며, 클래스의 불변속성을 강화할 수 있을 뿐 아니라, 내부 구현의 융통성도 발휘할 수 있습니다.
2. protected는 public보다 더 많이 '보호'받고 있는 것이 절대로 아닙니다.
'언어 > C++' 카테고리의 다른 글
[Effective C++] 타입 변환이 모든 매개변수에 대해 적용되어야 한다면 비멤버 함수를 선언하자 (0) | 2020.01.24 |
---|---|
[Effective C++] 멤버 함수보다는 비멤버 비프렌드 함수와 더 까가워지자 (0) | 2020.01.23 |
[Effective C++] 함수에서 객체를 반환해야 할 경우에 참조자를 반환하려고 들지 말자 (0) | 2020.01.21 |
[Effective C++] '값에 의한 전달'보다는 '상수객체 참조자에 의한 전달' 방식을 택하는 편이 대개 낫다 (0) | 2020.01.20 |
[Effective C++] 클래스 설계는 타입 설계와 똑같이 취급하자 (0) | 2020.01.19 |