항목 30. 접근하기 어려운 멤버에 대한 비상수 포인터나 레퍼런스를 리턴하는 멤버 함수 사용을 피해라
이유
1. private의 데이터를 포인터나 레퍼런스로 리턴은 정보은닉 자체를 파괴하는 행위이다.
- 설계를 할때 성능에 중점을 둔다면 이런 경우가 생길수 있다고 필자는 설명한다.
해결방법
1. 우선 하지 말라;
2. 만약 할수밖에 없다면, 상수로써 전달한다. const
주의점
1. 만약 상수성을 제거해야지만 사용해되어야 한다면, 그 데이터를 사용 할때 데이터가 변경되지 않는다는 보장이 있어야 한다,
2008/06/28 03:25 추가 주의점 1번의 경우, 내부 데이터를 상수성이 있는 핸들로 받아놨는데, 만약, 그것이 함수에 들어 갈때, 상수성을 없에야만 한다면(간혹 이런 함수들이 있었다.), 그 함수 내부에서 데이터 변경이 일어 나지 않는 다는것을 보장해야 한다는 뜻이라고 해석됨
개인적 생각
1. 항상 해당 데이터가 어떻게 쓸건지 주석이나 #define으로 표시해 두는것이 좋겠다.
이유
1. private의 데이터를 포인터나 레퍼런스로 리턴은 정보은닉 자체를 파괴하는 행위이다.
- 설계를 할때 성능에 중점을 둔다면 이런 경우가 생길수 있다고 필자는 설명한다.
해결방법
1. 우선 하지 말라;
2. 만약 할수밖에 없다면, 상수로써 전달한다. const
주의점
1. 만약 상수성을 제거해야지만 사용해되어야 한다면, 그 데이터를 사용 할때 데이터가 변경되지 않는다는 보장이 있어야 한다,
2008/06/28 03:25 추가 주의점 1번의 경우, 내부 데이터를 상수성이 있는 핸들로 받아놨는데, 만약, 그것이 함수에 들어 갈때, 상수성을 없에야만 한다면(간혹 이런 함수들이 있었다.), 그 함수 내부에서 데이터 변경이 일어 나지 않는 다는것을 보장해야 한다는 뜻이라고 해석됨
개인적 생각
1. 항상 해당 데이터가 어떻게 쓸건지 주석이나 #define으로 표시해 두는것이 좋겠다.
'책 정리 > Effective C++ 2판' 카테고리의 다른 글
인스턴스와 객체지향 설계 (0) | 2008.05.11 |
---|---|
34. 파일간의 컴파일 의존성을 최소화 하라 (0) | 2008.05.11 |
항목 33. 인라인을 선별적으로 사용하라. (0) | 2008.05.10 |
항목 32. 변수 정의는 가능한 뒤로 늦춰라 (0) | 2008.05.10 |
항목 31. 지역 객체에 대한 참조나 함수 내에서 new를 이용해 초기화된 포인터를 가리키는 참조를 리턴하지 말라 (0) | 2008.05.10 |
항목 29. 내부 데이터에 대한 "핸들"을 리턴하는 것을 피해라 (0) | 2008.05.10 |
클래스와 함수 : 구현 (0) | 2008.05.10 |
항목 28. 전역 네임스페이스를 분활한다. (0) | 2008.05.10 |
항목 27. 의도하지 않은 내부 생성 맴버 함수의 이용을 명시적으로 막는다. (0) | 2008.05.10 |
항목 26. 잠재적 모호성을 경계한다. (0) | 2008.05.10 |
최근댓글