객체 지향 프로그래밍

최종 확인 버전: 2014-03-12 12:50:42

• 컴퓨터 관련 정보 - 프로그래밍
  

Object-Oriented Programming, 줄여서 OOP. 배우는 사람을 OOPs! 소리 나오게 만드는 개념

요약하자면 데이터 구조에 접근할때는 제작자가 구현해서 같이 배포한 안정성이 보장된 방법만을 사용해서 프로그래밍 하라는 방식.

Contents

1 설명

2 장단점

[edit]

1 설명 ¶

컴퓨터 프로그래밍의 패러다임의 하나로, 프로그래밍 언어에 있어서 일대 혁명과도 같은 개념이다. 본래 당시 사용되었던 절차형 언어(procedure-oriented programming)[1]는 컴퓨터 프로그램을 명령어의 모음으로 보는 시각을 가지고 있었는데, OOP는 이러한 시각에서 벗어나 프로그램을 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하려고 하였다. 컴퓨터 프로그램은 전통적으로 논리적인 수행, 즉 입력을 받아 소스코드에 명시된 순서대로 처리한 다음, 그 결과를 내는 것 뿐이라는 생각이 지배적이었다. 또한 프로그래밍이란 어떻게 어떤 논리를 어떤 순서대로 써나가는 것인가로 간주되었다. 즉, 프로그램 자체가 가지는 기능에 대해서만 신경을 썼지, 이 프로그램이 대체 어떤 데이터를 취급하는 것인가에는 그다지 관심이 없었던 것이다.

이러한 결과로 절차형 언어는 데이터의 취급이 단순했고, 복잡한 현실 세계의 문제를 그 단순한 데이터만으로 표현하는 것이 힘들었다. 즉, 그런 방식으로는 크고 복잡한 프로그램을 구축하기 어려웠다는 것이다.

그런데 OOP는 이러한 당시의 패러다임에서 벗어난 새로운 시각을 가지게 된다. 즉, 프로그램에서 정말 중요한건 논리가 아니라 오히려 다루는 객체라는 것이었다. 객체라는건 OOP에서의 가장 작은 단위로, 조금은 다르지만 쉽게 생각하자면 어떤 데이터라고 할 수 있다. 이러한 객체의 예로는, 사람 이름, 주소, 전화번호 따위에서부터 건물, 매장위치나 컴퓨터 바탕화면의 버튼, 스크롤바 같은 것까지 모든것을 포함하게 된다.

이러한 OOP의 가장 기초적인 단계는 모든 객체와 이 객체들이 서로 어떤 연관성이 있는가 하는 것을 식별하는 작업이다. 흔히들 데이터 모델링이라고 하는 이 작업이 끝나면 객체 클래스로 일반화하는데, 이때 클래스란 같은 종류의 집단에 속하는 속성과 행위를 정의한 것으로, 책을 예로 들자면 이 세상의 모든 "책"의 공통점, 정도라고 말하면 될 것이다. 플라톤이 말하는 "이상적" 책의 개념이라든지. 어쨌던 일반화가 끝나면 그것이 담고 있는 모든 데이터의 종류와 그것을 다룰 수 있는 모든 논리 순서를 정의한다. 이때 논리 순서를 메서드라고 부른다. 이 객체(Object), 클래스(Class), 메서드(Method or Message)가 OOP를 이루는 기본 구성 요소이다.

OOP 는 사실 간단히 말하자면, Program organizer 라 볼 수 있다. 즉, 크고 복잡한 프로그램이 있을때, 절차지향 스타일로 만들어진 프로그램은 서로 복잡하게 엉켜있는 소위 스파게티 코드가 탄생하게 된다. 이런 스타일은 거대한 프로그램을 구축하기도 힘들지만, 유지보수나 디버깅시 한쪽을 고치면 그와 관련된 다른 여러부분에서 또다른 에러가 튀어나오는등 심각한 문제를 야기하게 된다. 반면, OOP 스타일로 짜여진 프로그램은 각 객체와 해당 객체에 사용되는 메소드들이 클래스라는 단위로 정리되어있으며, 이 클래스라는 단위는 서로 상속받는 관계가 아닌 한, 상호독립적이기때문에 이런 문제에서 훨씬 자유롭게 된다. 즉, 절차지향형 프로그래밍이 하나의 디렉토리에 영상, 음악, 텍스트등 모든 파일을 때려넣고 서로간에 여러가지 링크를 걸어놓은 구조라면, OOP 는 클래스라는 디렉토리를 이용하여 각각의 오브젝트를 정리해놓은 구조라 할 수 있다. 참고로, 프로그래밍 언어와 OOP 같은 개념은 사실 독립적이다. 즉, 언어적으로 OOP 를 따로 지원하지 않는 C 언어로도 OOP 를 구현할수는 있다. 다만, 자바나 C++ 같이 OOP 를 언어 자체에서 적극 지원하지는 않기때문에 좀 불완전하고, 몇몇 대형 프로젝트에 쓰이기도 했지만, 널리 쓰인다고 보기는 힘들다.

참고로, OOP 가 탄생하기 이전 수학에서 먼저 1940년대에 비슷한 움직임이 있었는데, 모든것을 집합으로 보는것에서 벗어나 Category 로 묶어 보는 Category theory 가 그것이다. 다만, 수학에서는 프로그래밍에서처럼 커다란것을 모듈화시켜 보다 알기 쉬운 단순한 개별자로 쪼개려는 목적보다는 증명을 손쉽게 하기 위해서[2] 혹은 집합으로 표현 안되는것을 다룰때 주로 쓰인다. 또한, 마이너한 분야이지만 집합론이 아닌 순수 Category 기반의 수학을 만든 사람도 있었다. 이경우, 집합론에 비해 더 큰 체계가 되기때문에 장점도 많지만, 집합론에 비해 복잡해서 그다지 안쓰이는듯.

Category 란 OOP 에서의 클래스와 비슷하게 특정 조건을 만족하는 여러 오브젝트와 그 오브젝트들 사이의 Morphism(메서드에 대응된다고 생각하면 된다.)으로 구성된다. 즉, 예를들어 가장 간단한 Category 는 Set 으로, 모든 각각의 집합들을 오브젝트로, 그리고 그 각각의 집합들 사이의 함수들을 Morphism 으로 정의하는것으로 구성된다. 그외 Top 라는 Category 는 모든 위상공간(Topological space)을 각각의 오브젝트로, 각 위상공간 사이의 연속함수들을 Morphism 으로 정의하여 하나의 Category 를 이루는식이다. 참고로, 함수형 프로그래밍 언어같은 경우 각각의 데이터 타입을 오브젝트로, 프로그램 자체를(함수형 언어에서는 프로그램 자체가 함수이다.) Morphism 으로 정의하면 하나의 Category 가 된다. Category 와 Category 를 매핑하는 것으로는 Functor 라는것이 있다. (Functor가 성립하려면 하나의 Morphism이 다른 Category의 Morphism과 대응되어야한다.) 프로그래밍과 비교하면 다른 언어로 이식하는게 된다.

간단히 말하면, 
1. 함수는 하나의 입력에 하나의 출력밖에 불가능하네?[3]
2. 게다가 이전에 무슨 변수를 입력했는지도 몰라 같은 함수를 여러 번 호출하려면 같은 입력값을 매 번 입력해야 하잖아?
3. 아 귀찮아. 데이터 몰아넣고 필요할 때마다 최소한의 입력으로 같은 데이터를 뽑아올 수 있다면 좋을 텐데...
4. 그리하여 함수와 변수의 집합인 객체가 탄생됨.

처음 보는 사람은 아니 이게 무슨 소리야!라고 생각할지도 모르겠지만 지극히 당연한 현상이니 그냥 넘어가라.

(산은 산이요 물은 물이로다)

[edit]

2 장단점 ¶

하여튼, 이러한 특징은 여차저차한 결과로 다음과 같은 장단점을 지니게 된다.

• 데이터 클래스 개념은 상속이라는 굉장히 뛰어나지만 마찬가지로 굉장히 개 같은 특성을 지니게 해준다. 이 OOP 특성 덕분에 면밀한 자료 분석[4], 개발시간 단축[5], 좀더 정확한 코딩[6]을 보증하지만 어려워! 특히, 다중 상속이 되면 엄청 복잡해진다. 그래서 다중 상속을 지원하지 않는 OOP 언어도 있으며, 다중 상속이 되는 C++ 같은 것도 다중 상속은 최대한 자제하라고 권장하고 있다.
  
• 클래스는 오로지 관련 데이터만을 정의하기때문에, 한 클래스의 인스턴트가 수행될 때 다른 프로그램의 데이터를 절대로 건드릴 수 없게 된다. 덕분에 높은 시스템 보안을 제공하고, 자료 훼손을 방지하는 효과가 있다.[7]
  
• 클래스의 정의는 최초로 생성한 프로그램뿐 아니라 다른 OOP에서도 똑같이 사용될 수 있다. 그리고, 이런 이유로 네트워크에 쉽게 분산 사용이 가능하다.[8]
  
• 데이터 클래스 개념은 언어에 정의되지 않은 새로운 데이터 형식을 프로그래머가 임의로 정할수 있도록 해준다.
  

뭐, 전체적으로 프로그램이 단순화되고, 생산성이 높은 시스템을 구축할 수 있다는 것. Smalltalk가 최초의 객체 지향 프로그래밍 언어 중 하나이고, 그 외에 C＋＋,Perl, Java, 액션스크립트, Objective-C, 루비, 파이썬같은 많은 객체 지향 프로그래밍 언어가 있다. 그리고 그 이후 만들진 언어들은 어떠하리.

참고로, 최근 주목을 받고있는 함수형 패러다임과는 다소 상반된 위치에 있다. OOP 의 경우, 프로그램 유지보수시 데이터 추가는 새로운 클래스를 더하는것으로 비교적 간단하게 가능하지만, operation set 을 변경할때는 관련된 다수 클래스를 수정해야 하므로 난잡해지는 경향이 있다. 반대로, 함수형 패러다임에서는 operation set 의 추가는 간단하지만, 데이터 추가는 관련된 다수의 함수를 바꿔야 하므로 난해한점이 있다. 주의할점은 OOP 와 함수형 패러다임이 상반된 위치에 있긴 하지만, 대비되는 개념은 아니며, 요즘에는 함수형 언어에도 OOP 개념을 추가한다던가(F#), 반대로 객체지향 언어에 함수형 패러다임을 추가하는(C#, C++, Python 등...)등 멀티패러다임 추세로 가고있다.

----

• [1] 대표적인 예로 C, Pascal, BASIC 같은
• [2] 몇몇 증명은 category 를 이용하면 엄청나게 간단히 증명이 된다. 문제는, 도대체 그게 어떻게 해서 증명되었는지도 오리무중인 증명이 많다는것. 덕분에, 증명의 원래목적('왜 그것이 성립하는가'를 알기위한 목적)과 거리가 멀다는 이유로 abstract nonsense 라 비하하는 수학자도 있다.
• [3] 물론 자료형을 정의하면 두 개 이상의 출력도 가능하다. 그런데 그 자료형이라는 게 객체...
• [4] 단, 초기 개발 요구사항 분석단계에서 글러먹으면 망했어요
• [5] 잘만들어진 클래스는 재사용성을 보장한다. Ctrl C+V신공보다 클래스 재사용이 낫다
• [6] 구현 목적을 위해 클래스를 나눌수 있으니 구현 단위와 목표가 뚜렷해진다.
• [7] 하지만 public을 남발해 버리면... 더 이상의 자세한 설명은 생략한다
• [8] 이러한 아이디어를 발전시킨 것이 MS의 COM이다. 현재 한국의 인터넷 환경에 암종으로 작용하는 Active X의 뿌리.