객체 지향 프로그래밍(Object-Oriented Programming, OOP)의 등장

프로그램을 설계하는 방법에는 여러가지 방법이 있지만, 프로그램 설계를 단순히 데이터와 처리로 나뉘는 것이 아닌,

프로그램을 각각 수많은 "객체"라는 단위를 기본으로 나누어 이를 각각 상호작용하도록 하는 방법 설계를 객체 지향 프로그래밍이라 합니다.

 기존 절차적 프로그래밍에서 기계, 데이터를 원료로 생각하고 데이터가 메쏘드 등을 통과하면서 순서대로 가동되어가는 방식이었습니다.

객체 지향 프로그래밍은 데이터를 중심으로 메쏘드에서 데이터에 접근해서 변경하는 개념이라고 보면 됩니다.

즉, 데이터가 각각 단계를 거쳐가는 것인지, 아니면 각각 단계가 데이터를 조작하여 변경되는지의 차이라고 보면 될 것입니다.

객체 지향 프로그래밍의 등장은 이전 프로그래밍을 이해해야만 왜 등장이 되었고 어떻게 사용해야되는지 알게됩니다.

 초기 프로그래밍 방법은 대부분 절차적 프로그래밍이었습니다.

단순히 입력이 되면 프로그램에 등록되어진 순서대로 처리한 후 결과를 보여주는게 전부 였습니다.

즉, 프로그램이 가지는 기능을 어떤 것을 등록해놓을 것인가만 신경을 썼고, 이 프로그램이 어떠한 데이터를 입력 받게 될까는 관심조차 없었습니다.

초기 프로그래밍 방법인 절차적 프로그래밍은 문제점이 심각했습니다.

간단한 알고리즘이 처리불가한 복잡도가 높아지는 순서도를 프로그래밍할 경우 순서도 조차 표현이 힘들정도로 꼬인 "스파게티 코드"가 만들어지게 되었습니다. 이러한 프로그램은 중복되는 코드가 증가하여 본인 뿐만 아니라 본인 외 개발자가 유지보수 할 경우 매우 힘들어지게 됩니다.

 이 문제를 해결하기 위해 에츠허르 다익스트라가 1968년 GOTO문의 해로움이라는 눈몬에서 프로그램을 함수(procedure) 단위로 나우고 프로시저 상호 호출을 하는 구조적 프로그래밍을 제안하면서 절차적 프로그래밍의 문제점에서 벗어나게 됩니다.

그러나, 이 또한 문제점이 발생하게 됩니다. 함수가 데이터를 처리하는 방법을 구조화 했을 뿐더러, 데이터 자체는 구조화하지 못했기 때문입니다. 이는 전역 네임스페이스 포화문제를 낳게 되었습니다. 즉, 변수이름을 모두 소진하여 변수명 자체를 짖기 힘든 상황이 되버린 것입니다.

클래스, 메쏘드 이름만 똑바로 지어놔도 가독성과 유지보수성의 절반 이상은 먹고 들어갈 수 있기 때문에 매우 중요한 문제였습니다.

게다가 실행 콘텍스트를 저장할 마땅한 방법이 없어지는 문제가 생겼습니다. 실행 콘텍스트는 특히 GUI에서 중요해지는 것으로 특정 화면의 에 따라 실행되는 함수가 상태에 따라 각각 동작되는 방식이 다르기 때문입니다. 이는 엉뚱한 데이터가 엉뚱한 함수에 전달되기도 하여 데이터의 오염의 문제가 발생하게 되었기 때문에 프로그래머가 한 함수의 작동에 영향을 받는 변수를 테스트하고 이때는 모든 변수를 테스트해야하는 어려움에 봉착하게 됩니다. 가령, 변수 갯수가 수백개 이하면 울며 겨자먹기로 어떻게든 처리를 하겠지만, 그 이상 수천, 수억개가 넘을 경우 프로그래머가 처리할 수 없는 상황에 놓이게되어 명시적으로 함수내에 접근제어를 추가하여 데이터의 범위에 대한 제한을 걸어 놓는 상황에 도래하게 됩니다. 이렇게 지역 변수 또는 구조체 등으로 어찌어찌 제어를 하지만 시급히 더 근본적인 해결책이 필요하게 됩니다.

 이 때 이 문제를 대한 대안으로 등장한 것이 객체 지향 프로그래밍(Object-Oriented Programming, OOP)입니다.