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




1. 문법적 일관성

데이터 멤버가 public이 아니라면 접근은

함수로 해야할 것이고, 공개 인터페이스에 있는 것들이

전부 함수뿐이라면, 그 클래스에 멤버에 접근하고 싶을 때

괄호를 붙여야 하는지 말아야 하는지 고민할 필요가 없다.




2. 데이터 멤버의 접근성에 대해 훨씬 정교한 제어를 할 수 있다.

멤버 함수를 통한 접근은 접근 불가, 읽기 전용, 읽기 쓰기 접근을

내가 직접 구현할 수 있다. 심지어는 쓰기 전용 접근까지도




3. 캡슐화

자동차가 지나가는 속도를 모니터링 하는 클래스가 있다.

class speedData{

...

public:

void Add(int speed);

double average() const;

...

}


평균 값을 구하는 average 함수를 구현하는 방법은 두 가지이다.

첫 번째, 평균값을 넣어두는 데이터 멤버를 반환하는 방법

두 번째, 함수가 호출될 때 마다 평균값을 계산해서 반환하는 방법

이렇듯 평균값 접근에 멤버 함수를 통해 하게되면

(평균값을 캡슐화 하게되면) 내부 구현을 이렇게 혹은 저렇게

바꿀 수 있게 되고, 사용자는 기껏 해봤자 컴파일만 다시하면 된다.




4. 구현상의 융통성을 전부 누릴 수 있다.

데이터 멤버를 읽거나 쓸 때 다른 객체에 알림을

보낸다든지, 클래스의 불변속성 및 사전조건, 사후조건을

검증한다든지, 스레딩 환경에서 동기화를 건다든지 하는 일이다.

(C# 에서는 프로퍼티라 한다.)




5. 불변속성

사용자로부터 데이터 멤버를 숨기면, 클래스의 불변속성을

항상 유지하는 데 절대로 소홀해질 수 없게 된다. 불변속성을

보여줄 수 있는 통로가 멤버 함수밖에 없기 때문이다.


캡슐화는 현재의 구현을 나중에 바꿀 수 있다. --> 3번 참고

데이터 멤버가 public으로 되어있다면 캡슐화되지 않았다는 뜻이고

현재의 구현을 나중에 바꾸게 되면 코드가 깨지게 된다.


public으로 데이터 멤버를 선언할 경우 이 데이터 멤버를

변경하고자 할 때, 이 데이터를 쓰고 있는 모든 부분을

수정해야 할 것이며, protected 데이터 멤버라고 해도

상속받는 모든 클래스의 코드가 깨지게 될 것이다.




POINT!!

1. 데이터 멤버는 private로 선언하자,

2. 접근 수준은 private(캡슐화 제공) 그리고 나머지 (캡슐화 없음)으로 구분하자.

+ Recent posts