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

수민·2023년 3월 24일

Effective C++

목록 보기

22/30

스콧 마이어스의 Effective C++을 읽고 개인 공부 목적으로 요약 작성한 글입니다!

💡 데이터 멤버는 private 멤버로 선언하자!

문법적으로 일관성있는 데이터 접근 통로 제공

세밀한 접근 제어

클래스의 불변속성 강화

내부 구현의 융통성 발휘
💡 protected는 public에 비해 더 많이 보호 받고 있는게 아니다!

🖊️ 데이터 멤버가 public이면 안되는 이유

문법적 일관성

데이터 멤버가 public이 아니라면,
사용자가 어떤 객체에 접근할 수 있는 유일한 수단은 멤버 함수일 것이다.
클래스의 공개 인터페이스에 함수만 있다면 너무나 easy
편할거다

데이터 멤버에 대한 세밀한 접근 제어

데이터 멤버를 public으로 했다면
모두가 이 멤버에 대해 읽기 + 쓰기 권한을 가진다.
근데 public으로 안하고 이 값을 읽고 쓰는 함수를 만든다면
접근 불가 / 읽기 전용 / 쓰기 전용
등
다 구현할 수 있다

class AccessLevels {
public:	
	...
    int getReadOnly() const { return readOnly; }
    void setReadWrite(int value) { readWrite = value; }
    int getReadWrite() { return readWrite; }
    void setWriteOnly(int value) { writeOnly = value; }
    
private:
	int noAccess;
    int readOnly;
    int readWrite;
    int writeOnly;
};

이렇게
세밀하게 접근을 제어할 수 있당

캡슐화 (encapsulation)

함수를 통해서만 데이터 멤버에 접근할 수 있도록 해놓아보자

상황에 따라 멤버 함수를 다르게 구현해야 할 때도 있다..
데이터 멤버를 함수 인터페이스 뒤에 감추면
내부 구현을 융통성있게 진행할 수 있다.

데이터 멤버를 읽고 쓸 때 다른 객체에 메시지 보내기
클래스의 불변속성, 사전 조건, 사후 조건 검증
스레딩 환경에서 동기화 걸기
등을 편하게 할 수 있다.

데이터 멤버를 캡슐화하면, 클래스의 불변속성을 유지할 수 있다.

public == 캡슐화되지 않았다 == 바꿀 수 없다

그니까
널리 쓰일 클래스일수록 캡슐화를 잘 해놔야 한다.

왜냐면

데이터 멤버가 변경되면 깨질 가능성을 가진 코드의 양에 반비례해서 데이터 멤버의 캡슐화 정도가 감소한다
데이터 멤버가 바뀌면 이 멤버에 의존하는 다른 코드들도 다 바꿔줘야 하잖아
그니까..
public이나 protected로 선언하고 사용하기 시작했으면 바꾸기 힘들다