객체지향 프로그래밍 (Object-Oriented Programming)

모든 저작권은 <생활코딩>의 생산자인 <egoing>님에게 있습니다.

문제시, 비공개로 전환하겠습니다.

<객체지향>
객체지향 프로그래밍은 크고 견고한 프로그램을 만들기 위한 노력의 산물이다.
객체지향이라는 큰 흐름은 현대적 프로그래밍 언어들을 지배하고 있는 가장 중요한 맥락이라고 할 수 있다.
하지만 자바스크립트의 객체지향은 다른 언어들의 객체지향과 사뭇 다르다.
특히 Java나 C++과 같은 주류 객체지향 언어에 익숙한 독자라면 극심한 혼란을 경험할 수도 있다.
바로 이러한 특성 때문에 웃으면서 들어갔다가 울면서 나오게 된다. 
하지만 최소한 주류가 된 언어라면 그 언어가 추구한 나름대로의 지향점이 있을 것이다.
그 지향점에 대해서 이해하고 언어를 대한다면 훨씬 더 즐겁게 언어를 음미할 수 있을 것이다.
특히 모든 처리의 중심에 함수를 두는 자바스크립트를 공부하다 보면 객체지향을 이렇게도 추구 할수도 있는 거구나 하는 놀라움을 느낄 수 있다.

1. 객체지향 프로그래밍

객체지향 프로그래밍(Object-Oriented Programming)은 좀 더 나은 프로그램을 만들기 위한 프로그래밍 패러다임으로 로직을 상태(state)와 행위(behave)로 이루어진 객체로 만드는 것이다. 이 객체들을 마치 레고 블럭처럼 조립해서 하나의 프로그램을 만드는 것이 객체지향 프로그래밍이라고 할 수 있다. 다시 말해서 객체지향 프로그래밍은 객체를 만드는 것이다. 따라서 객체지향 프로그래밍의 시작은 객체란 무엇인가를 이해하는 것이라고 할 수 있다.  말이 어렵게 느껴지지 않는가? 그것은 아직 객체 지향에 대한 체험이 없기 때문이다. 본 수업에서는 객체 지향에 대해서 코드 없이 이야기 할 수 있는 것들에 대해서만 이야기 할 생각이다. 객체 지향에 대한 오리엔테이션이라고 생각하고 가벼운 마음으로 나머지 내용을 읽어보자. 객체지향 프로그래밍을 학습하는데 장애 중의 하나는 번역이다. Object를 번역한 객체는 현실에서는 거의 쓰지 않는 말이고, 머랄까 철학적인 느낌을 자아낸다. 그래서 객체지향 프로그래밍을 처음 접하는 입문자들은 객체지향 프로그래밍을 철학적인 탐구의 대상으로 파악하는 경향을 보이는데, 필자의 생각에 이것은 공부를 어렵게 할 뿐 도움이 되지 않는다. 쉽게 생각하자. 객체는 변수와 메소드를 그룹핑한 것이다. 문법과 설계 객체지향 프로그래밍 교육은 크게 문법과 설계 두 가지로 구분된다. 문법 - 하나는 객체지향을 편하게 할 수 있도록 언어가 제공하는 기능을 익히는 것이다. 이러한 기능들은 if, for문처럼 문법적인 구성을 가지고 있다. 이 문법을 이해하고, 숙지해야 객체를 만들 수 있다. 객체를 만드는 법에 대한 학습이라고 할 수 있다. 우리 수업은 여기에 초점이 맞춰져 있다. 설계 - 두번째는 좋은 객체를 만드는 법이다. 이것을 다른 말로는 설계를 잘하는 법이라고 할 수 있다. 좋은 설계는 현실을 잘 반영해야 한다. 현실은 복잡하다. 하지만 그 복잡함 전체가 필요한 것은 아니다. 아래의 그림을 보자. 위의 그림은 런던의 지도다. 여러분이 지하철을 이용한다면 어떤 지도를 선호할까? 오른쪽 하단의 지도를 선호할 것이다. 왼쪽 상단의 지도는 현실의 복잡함을 나타낸다. 오른쪽 하단의 지도는 지하철 탑승자의 관심사만을 반영하고 있다. 역 간의 거리나 실제 위치와 같은 요소들은 모두 배제하고 있다. 복잡함 속에서 필요한 관점만을 추출하는 행위를 추상화라고 한다. 지하철 노선도가 디자인의 추상화라고 한다면 프로그램을 만든다는 것은 소프트웨어의 추상화라고 할 수 있다. 객체 지향 프로그래밍은 좀 더 현실을 잘 반영하기 위한 노력의 산물이다. 이것은 단순히 객체 지향의 문법을 이용해서 객체를 만든다고 달성되는 것이 아니다. 고도의 추상화 능력이 필요하다. 좋은 설계는 문법을 배우는 것보다 훨씬 어려운 일이다. 심지어 이것은 지식을 넘어서 지혜의 영역이다. 좋은 설계를 위한 조언들은 많지만 이러한 조언들은 조언자의 입을 떠나는 순간 생명력을 잃어버린다. 지식은 전수되지만 지혜는 전수되지 않기 때문이다. 스스로 경험하고 깨우쳐서 자기화시켜야 한다. 필자도 그 긴 여정을 따라가고 있는 견습생에 불과하다. 객체지향의 설계 원칙이나 객체 지향의 철학적인 의미는 대단히 중요하다. 하지만 이러한 것들을 지금 언급한다면 여러분은 미궁 속에 빠지게 될 것이다. 그래서 필자가 제안하는 것은 일단은 지식부터 익히자는 것이다. 언어가 지원하는 객체지향 문법을 배우고, 이것들이 어떻게 동작하는지를 충분히 이해한 다음에 비로소 설계 원칙도 이야기할 수 있고, 객체와 사물의 비유도 시도해 볼 수 있을 것이다. 여기서는 몇 가지 객체지향이 추구하는 지향점을 가볍게 이야기하고 다음 토픽부터 구체적인 문법을 알아볼 것이다. 부품화 프로그래밍은 정신적인 활동이다. 정신적인 것은 실체가 없고, 무한하고, 유연하다. 이러한 특성은 정신이 가진 장점이면서 소프트웨어의 극치다. 하지만 정신의 이러한 특성은 때로 오해나 모순 같은 문제점을 유발한다. 소프트웨어도 이러한 문제점을 그대로 상속받는다. 이러한 문제점을 극복하기 위한 노력 중의 하나가 부품화라고 할 수 있다. 객체 지향과 부품화를 동일시 할 수는 없지만 부품화라고 하는 소프트웨어의 큰 흐름은 객체 지향이 만들어지는데 지대한 공헌을 했다고 할 수 있다. 하드웨어에서 이루어지는 부품화의 예를 보자. 아래의 컴퓨터는 초창기의 컴퓨터다. 본체와 모니터와 키보드가 하나로 단일화되어 있다. 이것의 문제점은 분명하다. 모니터가 고장 나면 컴퓨터를 바꿔야 한다. 키보드가 고장 나도 컴퓨터를 교체해야 한다. 그래서 위와 같이 모니터와 본체와 컴퓨터를 분리했다. 다시 말해서 부품화 시킨 것이다. 기능들을 부품화 시킨 덕분에 소비자들은 더 좋은 키보드나 저렴한 모니터를 선택할 수 있게 되었다. 또 문제가 생겼을 때 그 문제가 어디에서 발생한 것인지 파악하고 해결하기가 훨씬 쉬워진다. 위의 그림에서 모니터와 키보드 그리고 본체를 분리하는 기준은 무엇일까? 그 기준을 세우는 것이 추상화일 것이다. 위 제품의 기획자는 컴퓨터를 입력과 출력 그리고 연산 & 저장으로 분류하고 있다. 이 분류에 따라서 부품들을 모으고 분리해서 모니터, 키보드, 본체와 마우스라는 개별적인 완제품을 만들고 있다. 이 완제품들을 부품으로 조합하면 컴퓨터라는 하나의 완제품이 만들어진다. 하지만 어떤것이 더좋은 것인지는 모른다. 부품화가 중요한 것임에는 분명하지만 그 보다 중요한 것은 적절함이다. 그래서 설계가 어려운 것이다. 객체 지향은 부품화의 정점이라고 할 수 있다. 하지만 우리는 아직 객체 지향을 배우지 않았다. 그래서 우리가 배운 것 중에서 부품화의 특성을 보여줄 수 있는 기능을 생각해보면 좋을 것 같다. 메소드는 부품화의 예라고 할 수 있다. 메소드를 사용하는 기본 취지는 연관되어 있는 로직들을 결합해서 메소드라는 완제품을 만드는 것이다. 그리고 이 메소드들을 부품으로 해서 하나의 완제품인 독립된 프로그램을 만드는 것이다. 메소드를 사용하면 코드의 양을 극적으로 줄일 수 있고, 메소드 별로 기능이 분류되어 있기 때문에 필요한 코드를 찾기도 쉽고 문제의 진단도 빨라진다. 그런데 프로그램이 커지면 엄청나게 많은 메소드들이 생겨나게 된다. 메소드와 변수를 관리하는 것은 점점 어려운 일이 되기 시작한다. 급기야는 메소드가 없을 때와 같은 상황에 봉착하게 된다. 메소드는 프로그래밍의 역사에서 중요한 도약이었지만, 이 도약이 성숙하면서 새로운 도약지점이 보이기 시작한 것이다. 그 도약 중의 하나가 객체 지향 프로그래밍이다. 이것의 핵심은 연관된 메소드와 그 메소드가 사용하는 변수들을 분류하고 그룹핑하는 것이다. 바로 그렇게 그룹핑 한 대상이 객체(Object)다. 비유하자면 파일과 디렉토리가 있을 때 메소드나 변수가 파일이라면 이 파일을 그룹핑하는 디렉토리가 객체라고 할 수 있다. 이를 통해서 더 큰 단위의 부품을 만들 수 있게 되었다. 객체를 만드는 법에 대해서 호기심이 생기지 않는가? 이런 호기심을 유발시키는 것이 이번 토픽의 목적이다. 객체를 만드는 법은 다음 토픽에서 알아보고 지금은 부품화에 대해서 조금 더 생각해보자. 은닉화, 캡슐화 그런데 부품화라고 하는 목표는 단순히 동일한 기능을 하는 메소드와 변수를 그룹핑한다고 달성되는 것은 아니다. 제대로된 부품이라면 그것이 어떻게 만들어졌는지 모르는 사람도 그 부품을 사용하는 방법만 알면 쓸 수 있어야 한다. 이를테면 모니터가 어떻게 동작하는지 몰라도 컴퓨터와 모니터를 연결하는 방법만 알면 화면을 표시 할 수 있는 것과 같은 이치다. 즉 내부의 동작 방법을 단단한 케이스(객체) 안으로 숨기고 사용자에게는 그 부품의 사용방법(메소드)만을 노출하고 있는 것이다. 이러한 컨셉을 정보의 은닉화(Information Hiding), 또는 캡슐화(Encapsulation)라고 부른다. 자연스럽게 사용자에게는 그 부품을 사용하는 방법이 중요한 것이 된다. 인터페이스 잘 만들어진 부품이라면 부품과 부품을 서로 교환 할 수 있어야 한다. 예를들어보자. 집에 있는 컴퓨터에 A사의 모니터를 연결하다가 B사의 모니터를 연결 할 수 있다. 또 집에 있던 모니터에 A사의 컴퓨터를 연결해서 사용하다가 새로운 컴퓨터를 구입하면서 B사의 컴퓨터를 연결 할 수 있다. 모니터와 컴퓨터는 서로가 교환관계에 있는 것이다. 이것은 모니터와 컴퓨터를 연결하는 케이블의 규격이 표준화 되어 있기 때문에 가능한 일이다. 아래의 그림을 보자. 모니터와 컴퓨터를 연결하는 케이블인 HDMI를 보여준다. 컴퓨터와 모니터를 만드는 업체들은 위와 같은 케이블의 규격을 공유한다. 모니터 입장에서는 컴퓨터가, 컴퓨터 입장에서는 모니터가 어떤 식으로 만들어졌는지는 신경쓰지 않는다. 각각의 부품은 미리 정해진 약속에 따라서 신호를 입, 출력하고, 연결점의 모양을 표준에 맞게 만들면 된다. 이러한 연결점을 인터페이스(interface)라고 한다. 위의 그림을 보면 HDMI 케이블의 연결점은 특유의 생김새가 있다. 만약 HDMI 케이블을 랜선을 연결하는 구멍에 연결하려고 한다면 어떻게 될까? 동작하지 않을 뿐 아니라 연결 자체가 되지 않는다. 인터페이스란 이질적인 것들이 결합하는 것을 막아주는 역할도 하는 것이다. 즉 인터페이스는 부품들 간의 약속이다. 이러한 약속을 프로그래밍적으로는 어떻게 구현하는가도 살펴본다. 지금까지 객체를 부품으로 비유해서 설명 했다. 그런데 비유는 비유일 뿐이다. 비유는 의도한 유사점 뿐만 아니라 의도하지 않은 차이점까지도 전달될 가능성이 있기 때문이다. 비유의 함정이라고 할 수 있다. 소프트웨어는 하드웨어가 아니다. 하드웨어가 할 수 없는 것을 소프트웨어는 할 수 있다. 그 중의 하나가 복제와 상속이다. 이러한 개념을 구체적인 문법 없이 설명하는 것은 효용이 크지 않을 뿐만 아니라 자칫 흥미를 저해할 위험이 있기 때문에 여기서는 설명하지 않았다. 소프트웨어가 있기 이전부터 하드웨어가 이룩한 성취를 잘 수용하면서 동시에 소프트웨어 다운 소프트웨어를 만드는 것은 우리에게 주워진 숙제라고 할 수 있다. 객체지향프로그래밍(OOP) : 로직을 상태와 행동(변수와 메소드)로 나누고 연관된 것들끼리 그룹핑한 것을 객체라 하고 이를 조립해 프로그래밍을 하는 것. - 객체지향의 여러 가지 특성들 1. 부품화 : 프로그램의 로직들을 기능별로 나눠 부품화하는 것 2. 은닉화, 캡슐화 : 로직을 온전히 부품화하기 위해 내부동작법은 숨기고 사용법만 노출하는 것  3. 인터페이스 : 부품들간의 접점에서의 규칙, 약속  4. 객체지향은 코드의 재활용성을 높인다.

2. 생성자와 new

JavaScript는 Prototype based programming에 속해있다.
전통적인 함수언어의 특징을 가지고 있는 것이 아니고 객체지향 프로그램 + 함수 언어의 특징이 Mix되었다.
C++/Java는 규제를 통해 프로그래밍의 정확성을 확보한 반면
JavaScript는 보다 자유로운 정의가 가능하다. (나름의 목표와 Vision이 있다.)

객체지향 프로그래밍은 연관되어있는 변수와 메소드를 하나의 객체에 grouping, categorization 하는 것이다.
객체지향은 좋은 로직을 만드는 것이다.

객체 객체란 서로 연관된 변수와 함수를 그룹핑한 그릇이라고 할 수 있다. 객체 내의 변수를 프로퍼티(property) 함수를 메소드(method)라고 부른다. 객체를 만들어보자. var person = {}  // -> 비어있는 객체 (object)를 만드는 것. person.name = 'egoing';  // 객체를 담고있는 변수에 . 을 찍고 이 그릇안에 name이라는 변수를 담는 것. 객체에 담겨있는 변수 = 속성(프로퍼티) person.introduce = function(){ // 객체에 담긴 또다른 프로퍼티 introduce. 프로퍼티에 함수가 담겨있다. 그때, 프로퍼티에 담겨있는 함수=메소드     return 'My name is '+this.name; //여기서 this는 바로 function()이 속해있는 객체 person의 {}의 name을 가리킨다. } document.write(person.introduce()); //  객체를 만드는 과정에 분산되어 있다. 객체를 정의 할 때 값을 셋팅하도록 코드를 바꿔보자. var person = {     'name' : 'egoing',     'introduce' : function(){         return 'My name is '+this.name;     } } document.write(person.introduce()); 만약 다른 사람의 이름을 담을 객체가 필요하다면 객체의 정의를 반복해야 할 것이다. 객체의 구조를 재활용할 수 있는 방법이 필요하다. 이 때 사용하는 것이 생성자다. var person 1 = {      'name' : 'egoing',      'introduce' : function() {             return 'My name is '+this.name;      } var person 2 = {      'name' : 'leezche',      'introduce' : function() {             return 'My name is '+this.name;      } } 위의 경우에는 메소드의 중복이 일어나고 있다. 이러한 중복을 방지하는 것이 생성자와 new이다. 생성자    생성자(constructor)는 객체 {} 를 만드는 역할을 하는 함수다. 자바스크립트에서 함수는 재사용 가능한 로직의 묶음이 아니라 객체를 만드는 창조자라고 할 수 있다. 자바스크립트에서 함수가 흔들리면 객체도 같이 흔들리게 된다. ***자바스크립트에서는 Class가 존재하지 않는다. new 함수()의 리턴값은 객체 {} 가된다. function Person(){} var p = new Person(); p.name = 'egoing'; p.introduce = function(){     return 'My name is '+this.name;  } document.write(p.introduce()); 함수를 호출할 때 new을 붙이면 새로운 객체를 만든 후에 이를 리턴한다. 위의 코드는 새로운 객체를 변수 p에 담았다. 여러사람을 위한 객체를 만든다면 아래와 같이 코드를 작성해야 할 것이다. --- function Person(){} var p1 = new Person(); p1.name = 'egoing'; p1.introduce = function(){     return 'My name is '+this.name;  } document.write(p1.introduce()+"<br />"); var p2 = new Person(); p2.name = 'leezche'; p2.introduce = function(){     return 'My name is '+this.name;  } document.write(p2.introduce()); --- 별로 개선된 것이 없다. --- function Person(name){     this.name = name;     this.introduce = function(){         return 'My name is '+this.name;      }    } var p1 = new Person('egoing'); document.write(p1.introduce()+"<br />"); var p2 = new Person('leezche'); document.write(p2.introduce()); --- 생성자 내에서 이 객체의 프로퍼티를 정의하고 있다. 이러한 작업을 초기화라고 한다. 이를 통해서 코드의 재사용성이 대폭 높아졌다. 코드를 통해서 알 수 있듯이 생성자 함수는 일반함수와 구분하기 위해서 첫글자를 대문자로 표시한다. 생성자 function Person(name)은 객체의 초기화(initialize) 또는 변수 및 메소드의 정의를 이뤄낸다. 자바스크립트 생성자의 특징 일반적인 객체지향 언어에서 생성자는 클래스의 소속이다. 하지만 자바스크립트에서 객체를 만드는 주체는 함수다. 함수에 new를 붙이는 것을 통해서 객체를 만들 수 있다는 점은 자바스크립트에서 함수의 위상을 암시하는 단서이자 자바스크립트가 추구하는 자유로움을 보여주는 사례라고 할 수 있다.

3. 전역객체

전역객체란? 전역객체(Global object)는 특수한 객체다. 모든 객체는 이 전역객체의 프로퍼티다. function func(){     alert('Hello?');     } func();  window.func();  // window가 객체이며 점 뒤의 func()은 속성이다. 근데 이 속성에 함수가 왔으므로 메소드이다. func()함수는 사실                               window라고하는 전역객체의 함수이다. func();와 window.func();는 모두 실행이 된다. 모든 전역변수와 함수는 사실 window 객체의 프로퍼티다. 객체를 명시하지 않으면 암시적으로 window의 프로퍼티로 간주된다.  var o = {'func':function(){     alert('Hello?'); }} o.func(); window.o.func(); 자바스크립트에서 모든 객체는 기본적으로 전역객체의 프로퍼티이다. 전역객체API ECMAScript에서는 전역객체의 API를 정의해두었다. 그 외의 API는 호스트 환경에서 필요에 따라서 추가로 정의하고 있다. 이를테면 웹브라우저 자바스크립트에서는 alert()이라는 전역객체의 메소드가 존재하지만 node.js에는 존재하지 않는다. 또한 전역객체의 이름도 호스트환경에 따라서 다른데, 웹브라우저에서 전역객체는 window이지만 node.js에서는 global이다.

4. this

this는 함수 내에서 함수 호출 맥락(context)를 의미한다. 맥락이라는 것은 상황에 따라서 달라진다는 의미인데 즉 함수를 어떻게 호출하느냐에 따라서 this가 가리키는 대상이 달라진다는 뜻이다. 함수와 객체의 관계가 느슨한 자바스크립트에서 this는 이 둘을 연결시켜주는 실질적인 연결점의 역할을 한다. 함수호출 함수를 호출했을 때 this는 무엇을 가르키는지 살펴보자. this는 전역객체인 window와 같다. function func(){     if(window === this){         document.write("window === this");     } } func();  결과는 window === this this라는 변수안에 담겨있는 값이 window에 담겨있는 값이다. 메소드의 호출 객체의 소속인 메소드의 this는 그 객체를 가르킨다. var o = {     func : function(){ //변수 o의 프로퍼티가 function() 함수이기 때문에 메소드이다.         if(o === this){             document.write("o === this");         }     } } o.func();    결과는 o===this 생성자의 호출