본문 바로가기
Programming/JavaScript

[ JavaScript ] 객체 지향 프로그래밍 | 추상화란 무엇인가

by 코뮤(commu) 2021. 2. 4.
728x90
반응형

이미지 출처 :  https://commons.wikimedia.org/wiki/File:JavaScript-logo.png


 

 

 

해당 포스팅은 생활코딩의 이고잉 님의 강의를 기반으로 개인 공부용으로 정리한 포스팅임을 미리 알립니다.

 

 

 


 

객체 지향 프로그래밍

 

 

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

좀 더 나은 프로그램을 만들기 위한 프로그래밍 패러다임으로,

로직을 상태(state)와 행위(behave)로 이루어진 객체로 만드는 것이라고 할 수 있습니다.

 

이 객체들을 마치 레고 블럭처럼 조립해서 하나의 프로그램을 만드는 것이 바로 객체지향 프로그래밍입니다.

 

다시 말해서 객체지향 프로그래밍은 객체를 만드는 것입니다.

 

 

따라서 객체지향 프로그래밍의 시작은 객체란 무엇인가를 이해하는 것이라고 할 수 있죠. 

 

 

 

설계 - 추상화란 무엇인가?

 

좋은 객체를 만드는 법을 다른 말로는 설계를 잘하는 법이라고 할 수 있습니다.

 

좋은 설계는 현실을 잘 반영해야 하지만, 현실은 복잡하죠.

무조건 그 복잡함 전체가 필요한 것은 아닙니다. 아래의 그림을 봅시다.

 

 

 

 

 

 

위의 그림은 런던의 지도입니다.

 

왼쪽 상단의 지도는 현실의 복잡함을 나타냅니다.

 

오른쪽 하단의 지도는 지하철 탑승자의 관심사만을 반영하고 있습니다.

역 간의 거리나 실제 위치와 같은 요소들은 모두 배제하고 있습니다.

 

이렇게 복잡함 속에서 필요한 관점만을 추출하는 행위를 추상화라고 합니다.

 

 

지하철 노선도가 디자인의 추상화라고 한다면, 프로그램을 만든다는 것은 소프트웨어의 추상화라고 할 수 있습니다.

객체 지향 프로그래밍은 좀 더 현실을 잘 반영하기 위한 노력의 산물입니다.

 

이것은 단순히 객체 지향의 문법을 이용해서 객체를 만든다고 달성되는 것이 아니라,

고도의 추상화 능력이 필요한 일입니다.

 

 

 

부품화

 

 

프로그래밍은 정신적인 활동입니다.

 

정신적인 것은 실체가 없고, 무한하고, 유연하죠.

이러한 특성은 정신이 가진 장점이라고 할 수 있지만,

정신의 이러한 특성은 때로 오해나 모순 같은 문제점을 유발하기도 합니다.

 

소프트웨어도 이러한 문제점을 그대로 상속받습니다.

이러한 문제점을 극복하기 위한 노력 중의 하나가 부품화라고 할 수 있습니다.

 

객체 지향과 부품화를 동일시 할 수는 없지만,

부품화라고 하는 소프트웨어의 큰 흐름은 객체 지향이 만들어지는데 지대한 공헌을 했다고 할 수 있습니다.

 

하드웨어에서 이루어지는 부품화의 예를 들어보겠습니다.

 

 

아래의 컴퓨터는 초창기의 컴퓨터입니다.

 

 

본체와 모니터와 키보드가 하나로 단일화되어 있는 것을 볼 수 있죠.

이것의 문제점은 분명합니다.

 

모니터가 고장 나면 컴퓨터를 바꿔야 하고, 키보드가 고장 나도 컴퓨터를 교체해야 합니다.

 

 

그래서 사람들은 위와 같이 모니터와 본체와 컴퓨터를 분리했습니다.

 

다시 말해서 부품화 시킨 것입니다.

 

기능들을 부품화 시킨 덕분에 소비자들은 더 좋은 키보드나 저렴한 모니터를 선택할 수 있게 되었습니다.

 

또 문제가 생겼을 때 그 문제가 어디에서 발생한 것인지 파악하고 해결하기가 훨씬 쉬워졌습니다.

 

 

위의 그림에서 모니터와 키보드 그리고 본체를 분리하는 기준은 무엇일까요?

 

그 기준을 세우는 것이 앞서 언급한 추상화일 겁니다.

 

위 제품의 기획자는 컴퓨터를 입력과 출력 그리고 연산 & 저장으로 분류하고 있습니다.

 

이 완제품들을 부품으로 조합하면 컴퓨터라는 하나의 완제품이 만들어집니다.

 

 

 

메소드는 부품화의 예라고 할 수 있습니다.

 

메소드를 사용하는 기본 취지는 연관되어 있는 로직들을 결합해서 메소드라는 완제품을 만드는 것 입니다.

그리고 이 메소드들을 부품으로 해서 하나의 완제품인 독립된 프로그램을 만드는 것이죠.

 

메소드를 사용하면 코드의 양을 극적으로 줄일 수 있고,

메소드 별로 기능이 분류되어 있기 때문에 필요한 코드를 찾기도 쉽고 문제의 진단도 빨라집니다.

 

 

그런데 프로그램이 커지면 엄청나게 많은 메소드들이 생겨나게 됩니다.

 

메소드와 변수를 관리하는 것은 점점 어려운 일이 되기 시작합니다.

 

급기야는 메소드가 없을 때와 같은 상황에 봉착하게 되고,

메소드는 프로그래밍의 역사에서 중요한 도약이었지만,

이 도약이 성숙하면서 새로운 도약지점이 보이기 시작한 것입니다.

 

 

그 도약 중의 하나가 객체 지향 프로그래밍입니다.

 

이것의 핵심은 연관된 메소드와 그 메소드가 사용하는 변수들을 분류하고 그룹핑하는 것입니다. 

 

 

 

 

 

 

 

객체지향 프로그래밍은 철학적인 느낌이 강한 워드라서 저도 그렇게 좋아하지 않는 단어입니다.

 

아직도 잘 모르겠고, 공부해야할 부분인 것 같습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

728x90
반응형