김성규 입니다.

홍환민님께서 두가지로 결론을 내리셨는데. 다르게 생각되어 첨언 합니다.
홍환민님께서 내린 결론은 아래와 같습니다.

1. 멤버 변수에 접근한다는 사실을 객체가 알 수 있다.
2. 인터페이스와 관련있다.


그러나, 함수 접근자를 두는 것은 객체지향 개념의 3대 요소중 Encapsulation에
해당합니다. 3대 요소라 하면, 상속, 폴리모피즘, 캡슐화가 되겠구요.

상속은 다 아실것이고,

폴리모피즘은 함수 오버로딩(overloading), 오퍼레이터 오버로딩등 같은 모양을 가지는 것에
대해서 다른 모양, 같은 의미를 부여하는 오버로딩을 말합니다. C에서 "+" 연산자는 정수와
실수형 연산자에만 사용이 가능했습니다. 문자열 이어붙이기는 strcat() 함수를
사용했지요. 그러나 AnsiString 타입이 선언되고 이 문자열 타입에 대한 이어붙이기
연산자 "+"를 오버로딩할 수 있게된 것입니다. 또 함수의 파라미터가 다른 함수를
정의해서 쓸 수 있는 함수 오버로딩도 되지요. add(int, int) add(float, float)
등이 되겠네요. 이러한 오버로딩은 언어의 일관성을 높여줍니다.
참고로 상속에서 말하는 오버리딩(overriding)과는 틀립니다.

마지막으로 캡슐화는 데이터의 물리적 구조와 논리적 구조를 분리하자는 것입니다.
즉, Tightly coupled 관계를 사용하지 말고 Loosely coupled 관계를 사용하자는 것입니다.

이것의 예를 들어보겠습니다. 만약, 최대 100개 정도의 데이터가 예상되는 것이 있어
자료구조를 배열로 잡아서 구현했습니다. 전체 프로그램의 라인수가 약 1만라인정도되고
이 자료구조에 접근하는 곳은 약 3000군데 정도에서 사용되었다고 합시다.

이러한 상황에서 만약 입력 데이터가 최대 100개에서 일시적으로 최대 10000개로 바뀌는
상황이 발생하여 배열로 처리할 수 없기에 리스트로 자료구조를 바꾸어야 한다면 자료구조에
직접 접근하는 3000군데를 모두 고쳐야 하는 상황이 발생합니다.
아마도 다들 경험해 보셨을 듯 합니다.

그러나 처음부터 다음과 같이 캡슐화가 되어 있다면 해당 물리 자료구조만 고치면 이를
사용하는 부분은 신경쓰지 않아도 됩니다.
유지보수 측면에서 엄청난 노력이 절감되고 협동 작업에도 도움이 됩니다.

이러한 객체지향의 개념들은, "객체가 개입하는 것" 또는 "인터페이스와의 관계"에
초점을 맞추기 보다는 코드의 재사용성, 유지보수의 편의성등에 초점을 맞춘 개념들입니다.
참고하십시오.

// 배열
class Data
{
private:
  TItem FData[100];

public:
  TItem GetAt(int Index) { return FData[Index]; }
  void SetAt(int Index, TItem Item) { FData[Index] = Item;  }
};

// 리스트
class Data
{
private:
  TList * FData;

public:
  TItem GetAt(int Index) { return FData->Items[Index]; }
  void SetAt(int Index, TItem Item) { FData->Items[Index] = Item;  }
};