[ Effective C++ ] 정리 모음집
" C++ 프로그래머의 필독서, 스콧 마이어스의 Effective C++ 를 읽고 내용 요약 / 정리 "
[핵심]
" 데이터 멤버는 반드시 private 멤버 이어야 한다! "
- 데이터 멤버는 private 멤버로 선언하자! 이를 통해 클래스 제작자는 문법적으로 일관성 있는 데이터 접근 통로를 제공할 수 있고, 필요에 따라서는 세밀한 접근 제어도 가능하며, 클래스의 불변속성을 강화할 수 있을 뿐 아니라, 내부 구현의 융통성도 발휘할 수 있다!
- protected는 public보다 더 많이 '보호'받고 있는 것이 절대로 아니다!
💡 데이터 멤버를 public 으로 두면 안되는 이유
📌 문법적 일관성
- 데이터 멤버가 public이 아니라면 객체에 접근할 수 있는 유일한 수단은 멤버 함수!
- 멤버에 접근하고 싶을 때 그냥 함수를 쓰면 되기 때문에 사용자 입장에서 생각할 일이 줄어든다.
📌 함수를 사용할 시 데이터 멤버의 접근성에 대해 훨씬 정교한 제어 가능!
- 접근 불가, 읽기 전용, 읽기 쓰기, 쓰기 전용 접근을 직접 구현할 수 있다.
- 어떤 식으로든 외부에 노출 시키면 안되는 데이터 멤버들이 꽤 많기 때문에 세밀한 접근 제어는 나름 중요하다.
📌 캡슐화
[예시 코드]
class SpeedDataCollection { public: void addValue(int Speed); double averageSoFar() const; }📕 자동차가 지나갈 때 마다 속도를 계산한 후 지금까지 수집한 속도 데이터 집합에 그 속도를 추가하는 프로그램을 구현해보자...
- 방법 1 : 지금까지 수집한 속도 데이터 전체의 평균값을 담는 데이터 멤버를 클래스 안에 두기
- 평균값을 유지하기 위한 공간 할당이 필요해져 객체 하나의 크기가 커진다.
- 현재의 평균값을 반환하기만 하면되는 인라인 함수라 효율이 좋다.
- 방법 2 : 호출 할 때마다 평균값 계산 하기
- 함수 자체의 속도는 느리지만 객체 하나의 크기는 방법 1 보다 작음.📢 두 방법 중 정답이 있을까?
- 상황마다 달라진다. 중요한건 "평균값 접근에 멤버함수를 통하게 한다"라는 점.
-
데이터 멤버를 함수 인터페이스 뒤에 감추게 되면 구현상의 융통성을 전부 누릴 수 있다.
- 데이터 멤버를 읽거나 쓸때 다른 객체에 알림 메세지 보내기
- 클래스의 불변속성 및 사전조건 · 사후조건 검증
- 스레딩 환경에서 동기화 -
캡슐화는 현재의 구현을 나중에 바꾸기로 결정할 수 있는 권한을 예약 하는 셈
- public은 '캡슐화 되지 않았다' 라는 것이고 즉, '바꿀 수 없다' 라는 의미
📢 public과 protected는 똑같다!
- 데이터 멤버가 해당 클래스에서 제거되면 깨질 수 있는 코드의 양에 반비례 해서 그 데이터 멤버는 캡슐화 정도가 감소한다.
- public 데이터 멤버를 제거 했을 때 이 멤버를 사용 중이던 코드는 얼마나 많을까....?
- protected 또한 파생 클래스 전부가.....
오코완~😤😤