분명 객체 지향 법칙은 할 수 있는 만큼 데이터를 캡슐화 하라고 주장하고 있다.

어떤 것을 캡슐화 하면 우선 외부에서 이것을 볼 수 없게 된다.

캡슐화하는 것이 늘어나면 그만큼 밖에서 볼 수 있는 것들이 줄어든다.

밖에서 볼 수 있는 것들이 줄어들면 그것들을 바꿀때 유연성이 커진다.

변경 자체가 영향을 줄 수 있는 범위가 변경된 것을 볼 수 있는 것들로 한정되기 때문이다.

이미 있는 코드를 바꾸더라도 제한된 사용자들밖에 영향을 주지 않는 융통성을 확보 할 수 있는데

이런 것들 때문에 캡슐화에 가치를 두는 것이다.

그 클래스의 private 멤버에 접근 할 수 있는 멤버함수(+프랜드 함수)의 개수가 늘어날수록

캡슐화 정도가 낮아진다고 볼 수 있는 것이다. 비멤버 비프렌드 함수는 private 멤버에

접근 할 수 없기 때문에 그 클래스의 캡슐화 수준은 유지하면서 인터페이스의 유연성을

높일 수 있는 것이다.

비멤버 함수를 쓴다고 해서 꼭 전역 함수를 쓸 필요는 없다. 다른 유틸리티 클래스 같은 곳의

정적 멤버 함수로 만드는 것도 괜찬다. 더 나은 C++ 스타일의 방식은 비멤버 함수로 두되

네임스페이스 안에 두는 것이다.

※ 멤버 함수보다는 비멤버 비프렌드 함수를 자주 쓰도록 합시다. 캡슐화 정보가 높아지고

패키징 유연성도 커지며 기능적인 확장성도 늘어납니다.

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

이를 통해 클래스 제작자는 문법적으로 일관성있는 데이터 접근 통로를 제공 할 수 있고

필요에 따라서 세밀한 접근 제어도 가능하며 클래스의 불변속성을 강화 할 수 있을 뿐 아니라

내부 구현의 융통성도 발휘 할 수 있다.

protected는 public보다 더 많이 보호 받고 있는 것이 절대로 아니다.

const Rational& operator*( const Rational& lsh, const Rational& ths )

{

Rational result( lsh.n * rhs.n, lhs.d * rhs.d );

return result;

};

복사생성자가 한번더 불리는게 싫어서 이렇게 한다면

지역객체의 경우엔 return과 동시에 소멸된다.

result안에 기본자료형만 있으면 다행인데 여러 객체가 있다면 버그를 만든다.

객체를 반환하여 생기는 복사생성 비용은 안전하게 하는데 드는 비용일 뿐이고

실제로 그리 비용이 많이 들지 않는다.