JAVA의 객체지향프로그래밍(OOP)에 대해 알아보자 - 추상화 편

지난 시간에는 객체지향 프로그래밍의 한 요소인 캡슐화에 대해 다뤄보았다. 이번 시간에는 객체지향 프로그래밍의 요소인 추상화에 대해 알아보고자 한다. 추상화란 말은 어려워 보이지만 실상 안으로 들어가 보면 생각하기에 따라 참 단순한 개념이라고 할 수 있다. 이번 포스팅에서는 최대한 이것을 알기 쉽게 설명해 보고자 한다.

첫 번째로 예를 들자면 강아지, 고양이, 양, 소 이렇게 4마리의 동물이 있다고 했을 때 이것들을 하나로 묶기 위한 공통의 카테고리를 뽑는다면 무엇으로 뽑겠는가? 필자라면 문제에 답이 있다고 동물이라는 카테고리로 강아지, 고양이, 양, 소를 묶을 것이다. 이렇게 동물이라는 카테고리로 묶는다고 하였을 때 동물이 추상 클래스(abstract), 그리고 강아지, 고양이, 양, 소가 동물이라는 추상 클래스를 상속(extends)해서 공통으로 사용을 하는 것이다.

위의 내용에 대해 조금 더 설명을 덧붙이자면 동물이라는 추상 클래스 내에는 여러 메서드가 공통으로 정의될 수 있다. 숨을 쉰다라는 메서드가 있을 수도 있을 것이고, 울음소리를 낸다라는 메서드도 있을 것이다. 밥을 먹는다라는 메서드도 있을 수 있다. 이렇게 동물이라면 공통적으로 할 수 있는 것들을 설계 한 다음 이제 강아지, 고양이, 양, 소의 클래스들은 이것들을 상속하여, 재정의(Override)하여 사용한다는 것이다.

두 번째로 또 하나의 예를 들어보자. 자동차를 만든다고 하자. 자동차의 종류는 다양하지만 실제 구조는 비슷하다고 볼 수 있다. 엔진, 시동을 켜는 행위, 바퀴를 교체하는 행위, 와이퍼를 켜고 끄는 행위 등 자동차에서 이루어지는 것들은 비슷하다.

이러한 공통적인 모습들을 하나의 추상 클래스로 만든다면 어떻게 될까? 다양한 종류의 차들... 예를 들면 K5, K7, 그랜져, 아반떼 할 것 없이 해당 클래스를 상속하여 재정의하여 사용할 수 있는 것이다. 그것은 곧 모든 차량에 대해서 개발자가 일일이 정의를 해줘야 하는 작업이 줄어든다는 말이다.

구현 클래스가 몇 군데 되지 않는다면 실무에서 해당 효과를 크게 체감하지 못할 수 있다. 하지만 구현 클래스의 숫자가 기하급수적으로 늘어나기 시작했을 때, 이러한 추상화가 되어 있지 않았다고 생각해보자. 자동차에 공통적인 기능이 추가되거나 수정이 되었을 때 여러분들은 모든 구현 클래스를 검색해서 일일이 찾아서 수정을 해야 한다. 그러던 중에 어떤 차는 또 빼먹을 수도 있다. 어떤 차는 잘못 수정을 할 수도 있다.

하지만 추상화가 구현되어 있다면, 여러분이 할 것은 단 하나다. 추상화에서 설계도로 쓰이는 추상 클래스에 수정을 가하면 된다. 그러면 자연스레 모든 자동차에 적용이 되는 모습을 볼 수 있을 것이다.

그리고 덧붙이자면 본 포스팅에서는 추상 클래스라고 하여 abstract 클래스를 예시로 제공하였다. 하지만 클래스의 뼈대가 되는 설계도의 경우 위와 같이 abstract를 사용하여 extends로 구현해도 되며, interface로 설계하여 implements로 구현을 해도 무관하다. 물론 실무에서 여러분들이 이것을 직접 설계하기까지는 꽤 많은 시간이 소요될 것이다(실제 실무에서 이런 설계는 아무에게나 시키지 않는다). 하지만 이것 하나만 확실히 알고 가자. 좋은 설계도를 만드느냐, 없느니만 못한 설계도를 만드느냐에 따라서 개발자들의 개발 능률이 달라진다는 것을 말이다. 그러니 적어도 개념만큼은 확실히 알고 무엇인가를 하도록 하자. 잘못된 개념 인식은 없느니만 못하다.