자바 객체지향, wrap-up

메소드, 클래스, 패키지, 접근제어자로 이어지는 이 모든 것의 기반에는 Object Oriented라는 자바의 세계관이 깔려있습니다.

저는 개인적으로 객체지향이라는 단어를 싫어합니다. 이러한 단어는 일본에서 프로그래밍 언어를 전해 받았던 과거의 잔재로 “객체”라는 말이나 “지향”이라는 말이 우리에게 주는 말에 대한 느낌(늬앙스)이 없습니다.

억울하지만, Java가 영어권에서 출발한 만큼 Object Oriented 이라는 원문이 오히려 더 와 닿을 수도 있습니다. 다만, Object라는 것을 너무 철학적으로 깊이 생각하기 보다는, 과거 절차지향 언어의 불편함을 극복하기 위해서 만든 새로운 자바 언어 세계관에서 나온 단어이며, Object 자체를 하나의 고유명사로 받아들이는 것이 더 좋을 듯 합니다.

앞서 살펴봤던 로직 부분은 모든 프로그래밍 언어의 공통적인 특징이라고 한다면, Object Oriented는 자바와 같은 부류의 언어만 가지고 있는 독특한 특성입니다.

레고

자바 언어는 쉽게 말해 레고처럼 프로그래밍 한다는 개념으로 받아들이면 좋습니다. 예전에는 변수의 덩어리, 함수의 덩이리 등으로 묶었던 것을, 더 크게 변수와 함수(메소드) 덩어리 하나로 묶어서 관리한다라고 생각하면 됩니다.

메소드 = 함수
클래스 = 변수와 메소드(함수)의 묶음
패키지 = 클래스의 묶음
접근제어자 = 클래스 내부의 변수와 메소드에 대한 접근 제어

이렇게 네 줄로 요약할 수 있을 것 같습니다.

자바는 만능?

레코처럼 만들면 프로그래밍이 쉬울 줄 알았습니다. 그런데, 현실은 또 항상 그렇지만은 않습니다.

자바가 지향하는 Object Oriented 프로그래밍은 아래와 같은 문제를 필연적으로 수반합니다.

첫째, 자바는 뭘 하던 일단 클래스 1개가 있어야 프로그램을 만들 수 있습니다. 아무리 간단한 프로그램이라도 무조건 클래스 1개를 만들어야 해서, 필요이상으로 많은 클래스를 만들어야 하는 경우가 있습니다.

둘째, 레고 블럭(클래스)을 잘못 만들면, 전체 프로그램이 바보가 됩니다. 또한, 중요 클래스를 운영중에 실수로 수정하면, 시스템 전체가 1개의 레고 블럭으로 인해서 마비되기도 합니다.

셋째, 클래스 간의 관계가 복잡해지면, 내용파악이 쉽지 않습니다.

클래스 다이어그램

현재는 자바 클래스와 패키지를 더 큰 단위로 묶어서 하나의 모듈처럼 사용하기 합니다. 하지만, 이 경우에도 위에서 발생하는 문제는 계속 따라 다닙니다.

다행인 것은 그러한 문제가 늘 있기 때문에 제가 먹고 살 수 있다는 것이지요. 아무리 프로그래밍 아키텍처가 발전하더라도 결국 하부의 내용을 알아야 문제를 해결할 수 있습니다.