객체지향 프로그래밍이라니 이름만 보고서는 아무 감이 잡히지 않는다.
여러 강의를 찾아봐도 형체없는것을 더듬고있는 기분.
하지만 이해하고싶어서 이것저것 찾아보며 알아본데까지 정리해보고 추가해나가려고 한다.
Object 객체, 물체
Oriented 방향을정하다
Programming 프그래밍
물체를 중심의 프로그래밍
모든것을 물체로 보려는 프로그래밍 을 의미.
객체지향말고 함수를 이용해 프로그램을 만드는 패러다임이 있었다.
이것들을 Procedural programming이라고 지칭하는데
Procedural(절차적) 이라는 기능을 중요하게 생각한다.
절차적 프로그래밍이란 단순히 순차적인 명령 수행이 아니라 루틴, 서브루틴, 메소드, 함수 등(이를 통틀어 프로시저라고 한다.)을 이용한 프로그래밍 패러다임을 뜻한다. 명령형 프로그래밍의 일종이다.
'절차적 프로그래밍'이라는 한국어 번역은 오해의 여지가 크다. Procedural Programming에서 Procedural를 '절차적'으로 번역해버려서 마치 절차적으로 실행하는 것이 중점이 되는 것처럼 보이기 때문이다.
그런데 절차적이지 않은 프로그래밍이란 건 애초에 존재하지 않는다. Procedural의 Procedure는 '절차'라는 의미가 아니라 '프로시저'(C언어를 포함한 대부분의 언어에서는 함수라고 불리는 그것이다)의 의미이다.
이 패러다임에서는 프로시저 콜, 즉 함수 호출을 통해서 추상화와 재사용성을 얻어내는 것이 본질이기 때문이다. 그러나 이미 교과서에 절차적 프로그래밍이라고 줄기차게 쓰여져 있어서 굳어져버렸기 때문에 어쩔 수 없이 이 번역명이 사용되고 있다.
또 다른 문제로는 객체지향 프로그래밍과 비교를 해서 마치 객체지향의 반대이며 심지어 네이밍이 절차지향으로 알고있는 사람들도 있는데 일단 절차지향이라는 용어는 잘못된 표현이며 절차적 프로그래밍이 맞다. 해외에 검색해서 절차지향이 조금 나오기는 하나 대부분은 절차적 프로그래밍이라는 용어를 사용한다. 두번째로 객체지향이 절차적 프로그래밍의 반대 급부처럼 사용되는 것인다. 객체지향의 반대가 절차적프로그래밍인것은 당연하지만 전혀아니다. 더 정확히 말하면 절차적 프로그래밍의 관점이 프로시져에서 객체로 확장된것에 가깝기에 일치된다고 보긴힘들지만 공유하는 부분이 더 많다. 애당초 둘다 명령형 프로그래밍의 하위개념이기에 반대급부로 사용될 수 없다. 그래서 보통 제대로된 서적에서는 굳이 비교를 하자면 "객체지향과 일반적인 절차적 프로그래밍(쉽게말해서 객체를 사용하지 않는)"이라는 단서를 붙힌다.
함수형 프로그래밍과도 비슷한 논란이 있는데 현대언어에서의 프로시져와 함수의 구분은 없어진거나 다름없기에 둘은 동등한건지에 대한 논란이 있으나 애당초 관점이 다른 용어이기 때문에 당연히 둘은 다르다. 함수형 프로그래밍의 관점은 순수함수와 일등객체인 함수에 관심이 있는 것이고 절차적 프로그래밍은 함수(그리고 이를 관리하는 모듈)에 의한 재사용성에 초점을 둔 것이다.
출처: 나무위키
Functions=routine=subroutine이고 함수를 이용해 프로그램을 만드는 패러다임을 말한다.
이런 procedural기반에서 procedural의 부족함을 보완한것이 object프로그래밍이다.
두가지의 중요한 차이는. procedural함수가 있었고, 함수보다 더 큰 틀의 정리도구인 '객체'가 존재한다는 것이다.
비유적으로 생각을 해보면 a라는 정보가 있다. 적으면서 기록했다. 종이에 기록하다가 많아지니 서로연관된 정보를 기록한 종이를 그루핑할필요가 있어졌다. 그렇게 책을 만들게되었다. 책이많아 책장을 만들고. 책장이 여러개가되어 서재를 만들었다. 서재가 커져서 도서관이 되었다.
정보기술의 발달로 전세계르 인터넷으로 연결해서 링크, 검색을 통해 정보검색할 수 있는 전세계적 규모의 도서관이 만들어진게 오늘날 우리가 사는 세상이다.
양이 늘어난다는것은 완전 다른 관리체계가 필요해진다는 것이다.
늘어나는 것을 관리할수 없다면 쌓이는 정보는 쓸모가 없어지고 양이늘어 괴로움만 줄 뿐이다.
프로그래밍도 처음엔 어떻게만들까에 집중해 만들어내다보니 시간이 지나면서 코드간섭이 일어나고 프로그램도 기하급수적으로 복잡해졌다. 인간이 감당할 수없는 수준의 복잡도에 도달해버린 프로그램을 어떻게 해야할까?
1. 들어있는 내용물을 버리고 새로운 기능을 넣는다.
2. 있는 기능을 잘 정리해서 그 기능을 작게 압축한다.
복잡한것의 복잡도를 낮추지 않으면 우리가 만들 프로그램을 더 나가가게 할 수 없어진 것이다.
널부러진 여러가지 장난감을 모아서 toy라고 이름붙인 상자에 넣으면, 이제 우리는 그 안에 뭐가 들었는지 신경쓰지 않고 상자의 이름만 신경쓰면 된다. 정리정돈되니 뇌가 편안해진다.
지금까지의 수납상자는 function 이었고 method였다.
function do( ){
복잡한코드~~~
복잡한코드~~~
복잡한코드~~~
복잡한코드~~~
}
우리는 이제 복잡한 코드는 신경쓰지 않고 do( )라는 함수를 호출해서 do의 기능을 쓸 수 있다.
함수do가 어떤일을 하는지 알면 세세한 내용을 신경쓰지 않고 가져다 쓸 수 있게된다.
복잡한 코드가 한줄의 코드로 간결해진다. 이것이 함수의 폭발적인 효과인것이다.
하지만 함수도 프로그래밍 역사에서는 나중에 등장한 것이다. 함수로 복잡도 낮추기에 성공해서 여유가생겼고
우리는 또 새로운 기능들을 추가하게된다.
여러함수가등장하고 또 인간이 감당하기 어려울정도로 많아진다.
관리하기위해 비슷한기능을 가진 함수들끼리 이름을 비슷하게하거나 같은위치에 모아두는 노력을 했지만
우리는 근본적 해결책을 생각해보게 된다.
그렇게 제시된 방법중 하나로 널리 사용되고있는것이 객체지향 프로그래밍이다.
서로 연관되어있는 함수와 변수들을 '객체'로 그루핑한다.
do1()
do2()
do3()
...
를 toy라는 이름의 객체로 묶는다.
그리고 이렇게 묶은 함수들을 부를때
toy.do1()
toy.dp2()
toy.do3()
라고 한다.
이런 방법으로 서로 연관된 함수들을 다른 함수와 구분되게 하는 것. 분류되게 하고 정리정돈 하는 것이 객체지향의 핵심 아이디어다. 물론 객체지향은 이 외에도 다면성을 가지고있다.
객체지향이 뭔지 한마디로 정의하는것은 인간이 무엇인지를 정의하는 일처럼 어려운 일이다.
객체지향의 다면성 중 하나인 연관된 함수와 변수를 그루핑하고 이름붙여 쓰는것.을 기억하고 출발하면 좋을것.이라고 한다.
어렵다..!
