객체지향은 어떻게 생겨나게 되었을까?

 

객체지향은 어떻게 생겨나게 되었을까?

우리는 객체지향을 이해하기 전에 어떤 배경으로 이것이 등장했으며, 그 전에는 어떤 방식의 프로그래밍 기법이 있었는지 알아야 한다.

 

 

순차적, 비구조적 프로그래밍(Sequential programming & Non-structured programming)

작성된 코드 그대로 위에서 아래 방향으로 순차적으로 동작하여 프로그램을 완성하는 방식이다. 

당연하게도 가장 초창기 프로그램 패러다임이며, 직관적이지만 비구조적이다.  

A -> B -> C의 동작중 C에서 A로 가야 할 일이 생기면 goto를 사용해야 한다.

당연하게도 goto를 무분별하게 사용한다면, 코드의 직관성을 잃게 된다. 

 

사실 100% 순차적 프로그래밍을 사용한다면 goto문을 사용하지 않는 게 맞다. 

goto를 사용하는 즉시 순차적이라는 단어의 의미를 잃기 때문이다. 

 

 

절차적, 구조적 프로그래밍(Procedural Programming & Structured Programming)

절차적 프로그래밍 계산기

절차적 프로그래밍의 핵심은 Procedueral이다.

Procedueral은 함수지만 이의 반환값보다 해당 함수를 사용함에 있어 그 기능에 의미를 둔다. 

예를 들어 C언어의 printf는 실제로는 Integer를 반환하지만 그보다는 stdout에 표시를 해주는 기능에 의미를 두고 사용한다. 여기서 printf()와 같은 맥락의 함수가 Procedueral이다.

 

이처럼 절차적 프로그램 반복적으로 사용되는 명령을 재사용이 가능한 Procedueral으로 분리, 사용하는 프로그래밍이다. 

이는 점차 발전하여 Procedueral의 묶음을 물리적으로 분리해 모듈의 형태를 갖추었으며 이를 구조적 프로그래밍이라 한다.

 

하지만 소프트웨어의 급격한 발전은 프로젝트의 규모와 복잡도를 키웠으며 Procedueral은 더 이상 해결법이 되지 못했다. 

 

예를 들어 유저 관리 프로그램을 만든다면, 유저에 대한 자료형과 이에 대한 함수가 필요하다. 

하지만 구조적 프로그래밍에서는 이 둘을 따로 생각할 수밖에 없다. 유저에 대한 자료형과 함수를 물리적으로 하나의 소스 파일에 두더라도 코드가 길어진다면 이 둘의 연관성을 알아차리기 어렵다. 즉 개념적으로 함께 할 수 없다. 

 

이러한 이유로 프로그램이 복잡해질수록 코드가 무한정 길어져 가독성이 떨어졌으며, 동작 순서에 따른 결괏값에 대한 보장이 없어 유지보수에 취약점을 가져왔다.

 

 

 

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

객체 지향 프로그래밍 계산기

그러자 사람들은 아주 간단 명료한 결론을 내린다.

특정 개념의 함수와 자료형을 묶어서 관리하고 이를 객체(Object)라고 부르자!

 

순차적으로 명령어의 나열을 바라보는것에서 벗어나 자료형(속성)과 메서드를 클래스로 정의하고 정의된 클래스를 통해 객체를 생성한다. 이렇게 생성된 각각의 독립된 객체는 유기적인 상호작용을 통하여 로직을 이루며 동작한다. 

 

초창기 객체지향 프로그래밍은 단순히 연관된 변수와 함수를 묶는 정도였지만 시간이 지남에 따라 은닉화, 캡슐화, 다형성, 상속을 추가함으로써 초기보다 훨씬 강력한 형태로 발전했다. 

 

객체지향은 아직까지는 대세적인 패러다임으로 자리 잡고 있다. 하지만 객체지향 또한 절대적인 위치는 아니다. 

프로그램이 커질수록 설계 과정에 많은 시간이 투자되며 객체의 수와 개념에 따라 상대적으로 속도가 느리고 많은 양의 메모리를 사용하는 경향이 있다. 

 

 

패러다임은 항상 변한다. 그러므로 패러다임에 갇혀있는 생각을 하기보다 상황에 따라 알맞는 기법을 사용하면 된다.