/ JAVASCRIPT

Javascript - JavaScript 객체지향 - 객체지향 프로그래밍 소개

Javascript

JavaScript 객체지향 프로그래밍 소개



객체지향 프로그래밍



객체지향 프로그래밍이(Object-Oriented Programming)란 OOP라고도 하고 핵심키워드는 객체이다. 객체지향 프로그래밍에서의 객체를 추상적으로 말하면 상태와 행위로 구분해 서로연관되어있는 상태와 행위를 그룹화 해놓은 것을 객체라고 할수 있다. 이 객체들을 마치 레고 블럭처럼 조립해서 하나의 프로그램을 만드는 것이 객체지향 프로그래밍이라고 할 수 있다. 다시 말해서 객체지향 프로그래밍은 객체를 만드는 것이다. 따라서 객체지향 프로그래밍의 시작은 객체란 무엇인가를 이해하는 것이라고 할 수 있다.

문법과 설계


객체지향 프로그래밍 교육은 크게 두 가지로 구분된다.

문법



하나는 객체지향을 편하게 할 수 있도록 언어가 제공하는 기능을 익히는 것이다. 이러한 기능들은 if, for문처럼 문법적인 구성을 가지고 있다. 이 문법을 이해하고, 숙지해야 객체를 만들 수 있다. 객체를 만드는 법에 대한 학습이라고 할 수 있다. 우리 수업은 여기에 초점이 맞춰져 있다.

설계



두번째는 좋은 객체를 만드는 법이다. 현실에서 우리가 관심이있는 어떤 특성, 어떤관점을 소프트웨어화 시켜서 문제를 해결하는것이 프로그램, 프로그래밍이다.

예시1

위의 그림은 런던의 지도이다. 이미지중 어떤것이 가장 보기 편할까. 마지막의 이미지가 보기 제일 편하지 않을까? 역과 역사이이의 환승역이라던지 노선들을 간단하게 추상화(abstract)시켜 보여주고 있다. 복잡함을 제외하고 사용자의 유일한 관심사에 초점을 맞춰 편의성을 높였다.
지하철 노선도가 디자인의 추상화라고 한다면 프로그램을 만든다는 것은 소프트웨어의 추상화라고 할 수 있다. 객체 지향 프로그래밍은 좀 더 현실을 잘 반영하기 위한 노력의 산물이다. 이것은 단순히 객체 지향의 문법을 이용해서 객체를 만든다고 달성되는 것이 아니다. 고도의 추상화 능력이 필요하다. 좋은 설계는 문법을 배우는 것보다 훨씬 어려운 일이다. 심지어 이것은 지식을 넘어서 지혜의 영역이다. 좋은 설계를 위한 조언들은 많지만 이러한 조언들은 조언자의 입을 떠나는 순간 생명력을 잃어버린다. 지식은 전수되지만 지혜는 전수되지 않기 때문이다. 스스로 경험하고 깨우쳐서 자기화시켜야 한다. 필자도 그 긴 여정을 따라가고 있는 견습생에 불과하다.
객체지향의 설계 원칙이나 객체 지향의 철학적인 의미는 대단히 중요하다. 하지만 이러한 것들을 지금 언급한다면 미궁 속에 빠지게 될 것이다. 그래서 우리가 할 것은 일단은 지식부터 익히자는 것이다. 언어가 지원하는 객체지향 문법을 배우고, 이것들이 어떻게 동작하는지를 충분히 이해한 다음에 비로소 설계 원칙도 이야기할 수 있고, 객체와 사물의 비유도 시도해 볼 수 있을 것이다. 여기서는 몇 가지 객체지향이 추구하는 지향점을 가볍게 이야기하고 다음 토픽부터 구체적인 문법을 알아볼 것이다.

부품화



객체지향 프로그래밍을 구성하고 있는 컨셉들은 상당히 많다. 하나의 프로그램이 여러개의 로직으로 이루어져 있다. 그 로직을 그룹화 시켜놓고 로직과 관련된 변수와 메소드들을 그룹화 해놓은게 객체이다. 이렇게 함으로서 재활용성을 높일수 있다. 그럼 이 객체를 다른곳에 사용한다는 것은 이객체가 다른 곳, 여러곳에서 일종의 부품으로서 사용된다는 것이다.
아래는 초창기의 컴퓨터이다.

옛날컴퓨터 본체와 모니터, 키보드가 하나로 단일화되어 있다. 어딘가 고장나면 컴퓨터를 바꿔야할수도 있다. 요즘컴퓨터 하지만 위의 이미지처럼 부품을 나누어 놓는다면 고장난 부품만 고치면 될것이다. (이미지 생활코딩 참조)
객체 지향은 부품화의 정점이라고 할 수 있다. 하지만 우리는 아직 객체 지향을 배우지 않았다. 그래서 우리가 배운 것 중에서 부품화의 특성을 보여줄 수 있는 기능을 생각해보면 좋을 것 같다. 메소드는 부품화의 예라고 할 수 있다. 메소드를 사용하는 기본 취지는 연관되어 있는 로직들을 결합해서 메소드라는 완제품을 만드는 것이다. 그리고 이 메소드들을 부품으로 해서 하나의 완제품인 독립된 프로그램을 만드는 것이다. 메소드를 사용하면 코드의 양을 극적으로 줄일 수 있고, 메소드 별로 기능이 분류되어 있기 때문에 필요한 코드를 찾기도 쉽고 문제의 진단도 빨라진다.
그런데 프로그램이 커지면 엄청나게 많은 메소드들이 생겨나게 된다. 메소드와 변수를 관리하는 것은 점점 어려운 일이 되기 시작한다. 급기야는 메소드가 없을 때와 같은 상황에 봉착하게 된다. 메소드는 프로그래밍의 역사에서 중요한 도약이었지만, 이 도약이 성숙하면서 새로운 도약지점이 보이기 시작한 것이다.
그 도약 중의 하나가 객체 지향 프로그래밍이다. 이것의 핵심은 연관된 메소드와 그 메소드가 사용하는 변수들을 분류하고 그룹핑하는 것이다. 바로 그렇게 그룹핑 한 대상이 객체(Object)다. 비유하자면 파일과 디렉토리가 있을 때 메소드나 변수가 파일이라면 이 파일을 그룹핑하는 디렉토리가 객체라고 할 수 있다. 이를 통해서 더 큰 단위의 부품을 만들 수 있게 되었다. 객체를 만드는 법에 대해서 호기심이 생기지 않는가? 이런 호기심을 유발시키는 것이 이번 토픽의 목적이다. 객체를 만드는 법은 다음 토픽에서 알아보고 지금은 부품화에 대해서 조금 더 생각해보자.

은닉화, 캡슐화



제대로된 부품이라면 그것이 어떻게 만들어졌는지 모르는 사람도 그 부품을 사용하는 방법만 알면 쓸 수 있어야한다. 모니터가 어떻게 동작하는지는 몰라도 컴퓨터와 모니터를 연결하는 방법을 알면 모니터를 설치해 사용할 수 있는것과 같다. 즉 내부동작 방법을 단단한 케이스(객체)안으로 숨기고 사용자에게 그 부품의 사용방법(메소드)만을 노풀하고 있는 것이다. 이러한 컨셉을 정보의 은닉화(Information Hiding), 또는 캡슐화(Encapsulation)라고 부른다. 자연스럽게 사용자에게는 그 부품을 사용하는 방법이 중요한 것이 된다.

인터페이스



좋은부품의 또다른 특징은 인터페이스이다. 잘만든 부품은 서로 교환할 수 있어야 한다. 모니터를 바꾼다고 가정해보자 서로다른 회사의 모니터를 교환하려고 하면 회사가 다르더라도 모니터를 연결할 수 있어야 한다. 이것은 컴퓨터와 모니터를 연결해주는 케이블이 표준화 되어있기 때문에 가능한 것이다.
컴퓨터와 모니터를 만드는 업체들은 HDMI케이블 규격을 공유한다. 각각의 부품은 미리 정해진 약속에 따라 신호의 입출력을 가능하게 해주는 연결점의 모양을 표준에 맞게 만들면 된다. 이러한 연결점을 인터페이스Interface)라고 한다. 즉 인터페이스는 부품들 간의 약속이다. 프로그래밍에서도 인터페이스에 해당하는것을 소프트웨어 적으로 제공하고 있다. 이러한 약속을 프로그램밍 적으로는 어떻게 구현하는가도 알아보자.
지금까지 객체를 부품으로 비유해서 설명 했다. 그런데 비유는 비유일 뿐이다. 비유는 의도한 유사점 뿐만 아니라 의도하지 않은 차이점까지도 전달될 가능성이 있기 때문이다. 비유의 함정이라고 할 수 있다. 소프트웨어는 하드웨어가 아니다. 하드웨어가 할 수 없는 것을 소프트웨어는 할 수 있다. 그 중의 하나가 복제와 상속이다. 이러한 개념을 구체적인 문법 없이 설명하는 것은 효용이 크지 않을 뿐만 아니라 자칫 흥미를 저해할 위험이 있기 때문에 여기서는 설명하지 않았다. 소프트웨어가 있기 이전부터 하드웨어가 이룩한 성취를 잘 수용하면서 동시에 소프트웨어 다운 소프트웨어를 만드는 것은 우리게게 주워진 숙제라고 할 수 있다