프로그램 작성 - 객체지향일까, 구조적일까?
과제용 프로그램을 만들다 보면, 프로그램을 객체지향 방식으로 짜야 할지 구조적 방식으로 짜야 할지 고객께 조언해 드려야 할 때가 자주 있어요. 물론 이때 가장 중요한 것은, 주문한 프로그램을 제출할 수업에서 어떤 방식으로 프로그래밍을 배웠느냐예요...그래서 저희가 만들 과제용 프로그램을 어떤 방식으로 작성해야 하는지는 사실 고객님이 저희에게 알려 주셔야 해요. 이 부분은 매우 중요하니 꼭 확인해 보시길 권해요. 이 점에서 잘못 판단하면 그 과목에서 낙제할 수도 있거든요.
다만 담당 교수님이 이 부분을 학생에게 자유롭게 맡겼다면, 솔직히 답은 한 단어로 줄일 수 있어요. 바로 객체지향이에요. 하지만 처음부터, 정의부터 시작해 볼게요.
구조적 프로그래밍은 절차적 프로그래밍 개념을 확장한 것으로, 코드를 계층적으로 모듈로 나누고 모듈끼리 엄격하게 정해진 인터페이스를 통해 소통하게 하는 프로그램 작성 방법론이에요. 데이터, 프로시저, 함수는 서로 직접 연결되어 있지 않고, 명령은 순차적으로 실행돼요. 구조적 프로그래밍의 기초는 조건문과 반복문이며, 온갖 종류의 점프는 나쁜 습관으로 여겨요. 선형 프로그래밍의 잔재로서 소스 코드의 가독성을 해치고 분석을 어렵게 만든다고 (당연히) 보기 때문이에요.
반면 객체지향 프로그래밍은 프로그램의 데이터와 동작을 하나로 묶은 객체로 프로그램을 정의하는 컴퓨터 프로그램 작성 방법론이에요(동작은 프로시저와 함수로 정의하며, 객체지향에서는 이를 메서드라고 불러요). 프로그램은 이런 객체들의 합으로 표현되고, 객체들은 프로그램에 주어진 작업을 수행하기 위해 서로 소통해요. 덕분에 소프트웨어의 각 부분을 맡은, 서로 협력하는 객체들을 조립해서 프로그래머 팀이 큰 프로젝트를 효율적으로 만들 수 있어요.
객관적인 정의는 이 정도로 하고, 이제 (틀림없이 전혀 객관적이지 않은) 의견을 말씀드릴 차례예요. 제 생각에 객체지향 프로그래밍은 어느 정도의 규율과 제약을 요구해서 프로그래밍을 배우려는 초보자들이 흔히 의욕을 잃기도 하지만, 객체지향의 원리를 알아 가는 데 시간을 조금만 들여도 분명한 이점이 있어요.
데이터에 대한 객체지향적 접근과, 프로그래머 팀 전체가 객체지향으로 프로그램을 작성할 때 생기는 가능성은 대단히 중요해 보여요. 현실에서는 서로 얼굴도 모르는 사람들이 클래스 메서드의 인터페이스 설명만으로 서로 소통하면서, 내부를 들여다볼 필요 없이 함께 거대한 애플리케이션을 만들어 내요. 객체지향 프로그래밍의 또 다른 장점은 코드가 읽기 쉽고 명확하다는 거예요. 정의 파일을 한 번만 훑어봐도 잠시 뒤에는 어떤 클래스나 메서드가 무슨 일을 맡는지 알 수 있어요.
구조적 프로그래밍은 상황이 꽤 달라요. 우선 규모가 큰 애플리케이션에서 읽기 쉬운 코드를 만들기가 매우 어려워요. 둘째, 한번 작성한 코드는 재사용에 적합하지 않아요. 다른 용도에 맞추려면 보통 여러 곳을 아주 많이 고쳐야 하기 때문이에요. 그래서 구조적으로 작성한 프로그램은 다시 쓰일 가능성이 낮아요. 프로그래머는 보통 옛 코드를 끝없이 만지작거리는 것보다 새 클래스를 처음부터 쓰는 편이 시간이 덜 걸려요.
이렇게 분명한 사실에도 불구하고, 대학에서는 구조적 프로그래밍을 훨씬 더 자주 가르치고, 학생들이 제출해야 하는 과제용 프로그램도 그런 방식으로 작성한 것이에요. 물론 객체지향이 이미 표준인 컴퓨터공학 전공에는 해당하지 않지만, 컴퓨터와 직접 관련이 없는 전공에서는 여전히 드물어요.
이 글을 마치며, 제가 쓴 몇 마디가 여러분이 객체지향 프로그래밍을 배우도록 설득했기를 바라요. 이 주제를 다 다뤘다고 착각하지는 않아요. 몇 가지 문제만 건드렸고, 객체지향 프로그래밍의 장점도 일부만 설명했을 뿐이에요. 구체적인 과제를 하다 보면(특히 팀으로 작업해야 할 때) 훨씬 더 많은 장점을 발견하게 될 거예요.