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

[fkdl0048]

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

제목 그대로 데이터 멤버가 private에 선언되어야 하는 이유에 대해서 다룬다. 사실 이 내용은 꼭 effective c++이 아니더라도 clean code, 객체지향 관련 책 등 코드 작성의 기본적인 원칙으로 여겨진다. 그 이유는 객체지향의 성질인 캡슐화 떄문이다.

일단 문법적으로 접근해보자. 협업을 하는 환경에서 함수의 멤버에 접근할 때, 메서드 호출인 괄호가 아닌 public을 통한 직접 접근이 같이 사용된다면 사용자는 헷갈리 수 밖에 없다. private 함수 호출로 통일하게 된다면 다른 고민없이 자연스러운 흐름이 팀 자체에 적용된다.

다음은 데이터 멤버의 제어부분이다. public으로 작성하여 이 멤버에 대한 읽고 쓰기 접근권한을 갖게 된다면 해당 멤버 변수에 대한 제어가 불가능함을 말한다. 예를 들어 해당 변수의 불변속성을 보장하기 위해 readonly나 해당 변수의 값의 범위를 제한하기 위한 get내부 구현 (예를 들어 Clamp가 있을 것 같다.)

C#에선 이를 프로퍼티로 두어 좀 더 쉽게 사용하는 느낌이다.

마지막으로 캡슐화의 관점이다. 데이터 멤버에 대한 접근을 함수로만 제한한다면 해당 멤버에 사용되는 계산식을 이후에 수정할 수 있고 (해당 클래스만 수정하면 사용하는 클래스들은 리빌드가 필요 없음) 해당 로직의 입구가 하나로 통일된다.

데이터 멤버를 함수 인터페이스 뒤로 감추게 되면 구현상의 융통성을 전부 누릴 수 있다. 데이터 멤버를 읽거나 쓸 때 다른 객체에 알림 메시지를 보낸다든지, 클래스의 불뱐속성 및 사전 조건, 사후 조건을 검증한다던지, 스레딩 환경에서 동기화를 건다던지 하는 일이다.

즉, C++에서는 public은 캡슐화되지 않았다는 것을 의미한다. C#도 마찬가지로 생각되며 꼭 해당 클래스의 public을 나열해보면 해당 클래스의 역할을 쉽게 파악할 수 있다.

정리

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

확실히 이에 대한 체감은 테스트 코드를 작성하거나 코드의 덩치가 커지게 되면서 분명하게 발생한다. 만약 자신이 하려는 행동에 대한 경로가 잘 그려지지 않는다면 그것은 분명 캡슐화가 제대로 되어 있지 않기 때문이라고 생각한다.