ETC

1. 객체 지향 개념의 원리

 “객체 지향이란 무엇인가 ?” 불행하게도 이 질문에 대한 명확하고 간결한 답은 존재하지 않는다. 대부분의 학문적 개념은 형식적인 정의(formal definition)를 통하여 그 개념이 정립되는 것이 일반적이다. 그러나 “객체 지향”에 대한 학문적 정의는 존재하지 않는다. 왜냐하면 이 질문은 마치 “인간이란 무엇인가 ?”라는 질문과 유사하기 때문이다. 유사 이래로 “인간이란 무엇인가 ?”에 대하여 수많은 철학자들이 그 답을 찾기 위해 노력하였지만 아직도 인간에 대하여 간결하며 엄밀하게 정립된 정의는 없다. 그러나 이 질문에 대한 답이 존재하지 않는다고 해서 우리가 인간을 이해할 수 없는 것은 아니다. 우리는 인간의 여러 속성(예를 들어 “인간은 걸어 다닌다.”, “인간은 생각한다.”, “인간은 웃는다.”, “인간은 사회생활을 한다.”)을 통하여 인간을 이해할 수 있으며 어떠한 것이 인간이고, 어떠한 것이 인간이 아닌가 하는 것을 구별 할 수 있다. 객체 지향에 대한 이해도 이와 마찬가지이다. 우리는 객체 지향에 대한 정의를 통해서 객체 지향을 이해할 수는 없지만 객체 지향이 갖는 특성들을 통해서 이를 이해할 수 있다.

 객체 지향임을 밝히는 필수적인 특성으로 나열될 수 있는 것은 자료 추상화(data abstraction), 상속(inheritance), 다형 개념(polymorphism), 동적 바인딩(dynamic binding) 등이 있다.

2. 기본 지식

2.1 객체 지향 용어

 “객체 지향”이라는 용어는 앞에서 언급한 바와 같이 정확한 정의가 없는 것이 특징이다. 그러나 다음과 같은 방법으로 기술될 수 있다.

 객체 지향 기법에서는 실세계에 존재하는 객체를 소프트웨어로 변환시키는 과정에서 실 객체가 소프트웨어의 객체로 자연스럽게 변환되는 것을 허용한다. 따라서 객체 지향 기법에서는 실세계의 모델링이 용이하며 전체 작업을 객체 위주의 작은 작업 단위로 나누기가 쉽다. 객체 위주로 분리되는 소프트웨어 단위는 이해하고 구현하기가 용이하며 재사용 가능하다.

 소프트웨어의 관점에서 객체 지향 기법은 자료 구조와 그에 대한 연산이 묶여서 구성되는 객체들을 정의하고 이들을 적절히 조직함으로써 소프트웨어 구조를 구성하는 것을 말한다. 따라서 객체 지향 기법은 관습적인 프로그래밍 기법과 비교할 때 자료 구조와 그에 대한 연산의 연결성의 강도에서 차이가 있다. 즉 기존 기법에서는 자료 구조와 연산과의 관계가 느슨한 반면 객체 지향 기법에서는 연결 관계가 강하다.

 “객체”와 “클래스”의 구분, 다형 개념의 의미, 추상 클래스의 의미 등이 그 용어를 사용하는 사람마다 다르게 해석되곤 한다. 따라서 객체 지향과 관련된 용어를 이해하고자 할 때 문맥에 따라서 신중을 기해 해석해야만 한다.

2.2 추상화

 소프트웨어를 개발하는 작업의 본질적인 의미는 “simulation”이다. 즉 실세계의 정보나 상황 중에서 주된 관심의 대상이 되는 부분을 컴퓨터 내부로 이식시키는 것이다. 그런데 실세계 상황의 복잡성으로 인하여 실세계의 상황을 바로 컴퓨터 내부로 반영할 수는 없으며 “추상화”와 “구체화” 과정을 거처야 한다. 즉 “추상화” 과정을 통하여 실세계의 상황을 간결하고 명확하게 “모델링”하게 되며 “구체화” 과정을 통하여 추상적 모델을 프로그램으로 변환한다. 시스템의 분석은 “추상화” 과정을 의미하며 이 과정에서 실세계의 상황이 정확하게 모델에 명시가 되지 않으면 프로젝트를 성공적으로 수행할 수 없기 때문에 분석의 중요성이 강조되는 것이다.

 시스템 분석자가 “추상화”를 통하여 이루고자 하는 목적은 두 가지이다. 그 하나는 “어떻게 하면 실제 시스템을 간결하게 표현할 수 있는가 ?”이고 또 다른 하나는 “어떻게 하면 실제 시스템의 정보를 모두 표현 하는가 ?”이다. 그런데 문제는 이 두 개의 질문이 서로 상치된다는 점이다. 즉 어떠한 시스템을 “간결하며 자세히” 표현한다는 것은 마치 동시에 두 마리의 토끼를 잡는 것과 비슷한 상황이기 때문에 결국 한 마리의 토끼도 잡지 못하는 상황에 도달하기가 쉽다. 따라서 분석가는 이러한 두 개의 목표를 잘 조절하여 모델링을 수행하는 능력이 필요하다. 그런데 “추상화” 작업을 이루기 위해서는 두 가지의 전제 조건이 마련되어야 한다.

 그 첫 번째는 “추상화”는 그 모델을 이해할 수 있는 “사회”를 기본 전제로 한다는 것이다. 예를 들면 건축 설계도는 건설업에 종사하는 사람들의 사회에서만 통용되는 추상화 모델이며, 미분 방정식은 수학과 관련된 일을 하는 사람들의 사회에서만 통용되는 추상화 모델이다. 두 번째 조건은 “추상화” 결과를 표현할 수 있는 표기법이 미리 정의되어 있어야 한다는 것이다. 이는 마치 음악가들의 사회에서 악보가 그들의 사고를 전달하는 표기법으로 사용되는 것과 같다. 음악가들은 악보라는 표기법을 이용하여 전 세계의 누구라도 같은 음악을 연주할 수 있는 것이다. 소프트웨어의 요구 사항 분석 결과도 마찬가지로 특정한 표기법을 통해서 표현되며 그 결과는 그 표기법에 익숙한 프로그래머들에 이해될 수 있어야 한다.

2.3 객체와 클래스

 객체 지향 분야에서 “객체”라는 용어와 “클래스”라는 용어가 혼용이 되고 있다는 점은 이들 용어를 사용하는 사람 입장에서 주의해야 할 사항이다. 문맥에 따라 이들을 혼용할 수 있는 이유는 “객체”라는 용어가 “클래스”보다 좀 더 포괄적인 의미를 갖기 때문이다. 더욱이 객체 지향 개념에 대한 깊은 성찰 이후에 깨달을 수 있는 점은 “객체”와 “클래스”의 구별이 큰 의미가 없다는 것이다. 그러나 객체 지향 언어의 관점에서는 “객체”와 “클래스”의 구별을 명확하게 하는 것이 바람직하기 때문에 용어에 대하여 알아야 한다.

 “객체”와 “클래스”의 구별은 기존의 프로그래밍 언어에서 변수에 대한 선언을 예로 들면 이해하기가 쉽다. C 언어에서 정수형 변수 x를 선언하기 위한 문장은 “int x;”이다. 이 문장에서 x는 객체에 해당되며 int는 클래스에 해당된다. 즉 프로그래밍 언어에서의 객체는 어떠한 정보를 표현하기 위해 할당된 기억 장소를 의미하며 클래스는 그 기억 장소의 속성을 기술하는 구조에 대한 명칭이다. 예를 들어 x가 나타내는 실 객체는 다음과 같은 선언을 이용하여 y나 z라는 명칭을 통해서도 접근할 수 있다.

 이러한 선언문 이후에 만약 “x = 10;”라고 쓰거나 “y = 10;”라고 쓰거나 혹은 “*z = 10;”이라고 쓰면 그 결과는 똑 같은 객체 안에 “10”이 저장되는 효과를 얻는다. 따라서 “객체 그 자체”와 “객체를 가리키는 명칭”을 확실히 구분할 수 있어야 한다. 특히 잘 작성된 객체 지향 프로그램에서는 같은 객체를 가리키는 명칭을 만들기 위해 주로 포인터 변수를 이용하므로 포인터 변수에 대한 이해를 분명히 해야 한다. (그림 2.1)는 객체의 명칭이 갖는 의미를 그림으로 나타낸 것이다.

그림 2.1 실 객체와 그에 대한 명칭들을 통한 접근

 정수형 객체 x에 대한 비유를 통하여 실제 객체 지향 프로그래밍 시에 “Student a;”와 같은 방식이 사용된다는 점을 이해할 수 있을 것이다. 이 문장은 “Student 클래스에 해당하는 객체 a를 만들어라.”라는 방식으로 이해하면 된다. 물론 이 때 클래스 “Student”는 이미 존재해야 하며 미루어 생각하건대 이 클래스에는 학생에 대한 정보를 저장할 자료 구조와 그 정보를 다루는 함수가 정의되어 있어야 할 것이다. 지금까지의 설명으로 “객체”와 “클래스”라는 용어의 구분이 이루어졌을 것이다. 다음에는 “객체”와 “클래스”가 어떠한 관계를 맺고 있는가에 대하여 알아보도록 한다.

 “객체”와 “클래스”는 방향성을 갖는 IS_A (is a) 관계를 갖는다. 예를 들어 “김태균은 남자이다.”라는 문장은 영어로 “KimTaegyun is a man.”으로 번역되기 때문에 IS_A 관계라고 한다. 이 문장에서 “김태균”은 객체이고 “남자”는 클래스이다. 그리고 이 문장이 방향성을 갖는다는 의미는 이 문장의 역이 성립하지 않음을 나타낸다. 즉 “남자는 김태균이다.”라는 문장은 성립하지 않는다. 그런데 혼동의 여지가 있는 점은 클래스들 간에도 IS_A 관계가 성립할 수 있다는 것이다. 예를 들어 “남자는 사람이다.” 그리고 “여자는 사람이다.”라는 문장을 사용하였을 경우 “남자”, “여자”, “사람”은 모두 클래스를 나타낸다. 이와 같이 클래스들 간에 IS_A 관계가 성립하는 경우는 “상속”이라는 개념을 통해서 프로그래밍에 반영될 수 있다. 객체 지향 개념에서 “객체”와 “클래스”라는 용어가 혼동이 되는 이유 중의 하나가 이와 같이 “객체와 클래스 간에” 그리고 “클래스와 클래스 간에” 똑같이 IS_A 관계가 성립하기 때문이다. (그림 2.2)는 이들의 차이를 나타내기 위한 그림이다.

그림 2.2 IS_A 관계의 사용

 그림에서와 같이 “객체”와 “클래스”를 그림으로 표현할 때 그 표기법을 달리하는 것이 일반적이다. 이 그림에서와 같이 한 “객체”와 한 “클래스” 간에 IS_A 관계가 성립할 경우 이를 객체 인스턴시에이션(object instantiation)관계라고 말한다. 예를 들어 “김태균” 객체는 “남자” 클래스의 한 인스턴스(instance)이다라고 기술한다. 모델링 시에 “객체”들을 그림으로 나타내면 객체의 수가 너무 많기 때문에 모델이 복잡해진다. 따라서 객체 지향 모델링 시에는 클래스들 만을 이용하여 그림을 그리는데 그 예가 (그림 2.3) 이다. IS_A 관계는 트리 구조로 표현되는데 각종 객체 지향 표기법에서는 이를 위한 독특한 표기법을 사용하고 있다. 앞으로 UML(Unified Modeling Language)이라고 하는 방법론을 주로 설명할 예정이기 때문에 (그림 2.3)는 UML을 이용하여 표현한 것이다. 이 그림에서 나타나는 일반화(generalization)와 상세화(specialization)라는 용어는 클래스들 간의 상속 관계를 방향성을 기준으로 지칭할 때 사용된다. 즉 “사람” 클래스의 특수한(상세화된) 경우가 “남자” 클래스이며, 역으로 “남자” 클래스를 일반화한 결과가 “사람” 클래스이다라고 기술한다. 클래스 간의 IS_A 관계는 다른 말로 “OR 관계”로 지칭되기도 한다. “OR 관계”로 지칭되는 이유는 (그림 2.3)의 경우 “사람의 종류에는 남자 OR 여자가 있다.”라고 기술될 수 있기 때문이다.

그림 2.3 IS_A 관계를 나타내는 UML 표기법

2.4 “같은 것” 과 “다른 것”

 객체 지향 분석을 할 경우에 분석가가 갖추어야 할 통찰력 중의 하나가 “같은 것”과 “다른 것”을 구별할 줄 아는 능력이다. 객체들 간의 동질성과 이질성을 구별해야만 우리는 동일한 객체들을 묶어서 하나의 클래스로 정의할 수 있다. 또한 객체들 간의 구분만 아니라 클래스들 간의 구분을 통해서 정확한 상속 계층을 유도할 수 있다. 즉 “객체”들의 구분을 통해서는 새로운 클래스를 유도할 수 있고 “클래스”들의 구분을 통해서는 클래스들 간의 상속 구조를 유도할 수 있다.

 어떠한 두 개의 사물이 “같은 가” 혹은 “다른 가”를 구별 하는 작업이 생각처럼 쉽지는 않다. 예를 들어 “비행기와 달이 같은가 혹은 다른가 ?”라는 질문에 대하여 생각해 보자. 이 질문은 다소 황당하며 대부분은 당연히 비행기와 달이 다르다는 결론을 내릴 것이다. 그러나 실제 답은 그렇지 않다. 우리가 어떠한 사물을 구분 짓기 위해서는 그 사물을 보는 관점의 기준을 우선적으로 설정하여야 한다. 즉 “비행기와 달은 하늘에 떠 있다는 점에서 같다.”라고 대답할 수 있다. 만약 우리가 어떠한 소프트웨어를 개발하는데 그 소프트웨어의 목적상 객체들을 “하늘에 떠 있는 것”과 “땅에 붙어 있는 것”으로 구별해야만 한다면 “달”과 “비행기”는 같은 클래스에 포함되어야 한다. 그리고 “사람”과 “바퀴 벌레”는 땅에 붙어 있다는 점에서 같은 클래스로 묶어야 할 것이다. 또한 객체나 클래스를 구분 짓는 관점의 기준은 상대적인 것이기 때문에 어떠한 동질성이나 이질성은 영원할 수가 없으며 응용 분야에 따라 달리 모델링 되어야 한다. 예를 들어 객체의 모습을 기준으로 객체를 구별해야 할 경우에는 “달과 동전이 같다.” 라고 말할 수 있으며 “달과 비행기는 다르다.”라고 말할 수 있다.

 사물의 공통점을 이용하여 실세계를 이해하는 기법은 어린 아이들에게서 쉽게 찾아 볼 수 있는 현상이며 따라서 우리는 어린 아이들이 언어를 배우고 사물을 익혀 가는 과정을 주의 깊게 살펴볼 필요가 있다. 실제 Xerox의 연구팀이 Smalltalk이라는 언어를 설계하면서 추구하였던 방향이 이와 유사하다.