자바 상속
목차
OOP설명의 어려움, 비판
드디어 자바 상속 챕터에 왔습니다.
컴퓨터 과학자들은 객체지향 프로그래밍이란 개념을 발전시키면서 엉뚱하게도 상속(inheritance) 이란 말을 떠올립니다.
객체지향 프로그래밍은 어떤 언어를 구사하건 막론하고 이해하기 어려운 학문인데요. 상속이란 개념도 그 이유에 한몫을 합니다.
일단 시중에 나와있는 교재들을 들여다 보면 다들 각자만의 예를 들어 상속에 대한 설명을 하려고 시도합니다.
뭐 흔하게는 동물의 계층관계 같은거죠. 생물 – 동물 – 포유류 – 인간 처럼 다윈에 기초한 생물학의 예를 들거나 또는 탈것 – 육상운송 – 자동차 – 승용차 이런 식도 있고요.
컴퓨터 게임에서는 객체 – 캐릭터 – 조종가능한 플레이어 같이 표현되기도 합니다.
요컨데 근본이 되는 개념, 어떤 존재가 있고 그 다음 단계 하위 계층(class)이라 부를 수 있는 종을 묶고 또 그 밑에 계속 공통점과 차이점을 찾아서 분리시켜 나갑니다.
이 일은 끓임없이 할 수 있어요. 동물로 부터 인간이 상속을 받았다면 인간 중에는 인종으로 나눌 수 있고 인종은 다시 국가 별로 분리할 수 있고 다시 그 나라의 남성, 여성으로 분리하고 남성중에 뭐 여성중에 뭐 이렇게 새로운 특성을 찾아 상속시켜 분리할 수 있는 범위는 무한합니다.
객체지향프로그래밍 이론은 무한함에 대한 끓임없는 사고 과정입니다. 때문에 이 블로그에서는 처음부터 자바는 OOP (Object Oriented Programming) 라서 어렵다고 계속 강조해왔던 겁니다.
한 가지 더 개인적 주관입니다만, 인간의 상위 클래스가 동물에서 상속받는다는 개념은 다윈의 진화론에서 가져온 아이디어입니다. 객체지향프로그래밍을 만든 사람들의 학문적 토양이 서양의 생물학이라는 것은 놀랄 만한 사실은 아닙니다.
사실 한국에서 다위니즘에 대한 아이디어가 거의 없지만 서양사회에서의 영향력은 절대적이라고 하죠. 영국에서는 아직도 가장 중요한 생물학자이자 사상에 영향을 끼친 것으로 인정받고 있습니다.
동양에서 객체지향 프로그래밍을 만들었다면 좀 달랐을 겁니다. 유교사상이라던가 불교의 환생 사상 같은 동양철학이 들어갔을 겁니다.
서론을 줄이려고 했으나 객체지향의 심오함을 이야기하기 위해서는 글자수가 늘어날 수 밖에 없다는 점을 양해바랍니다.
시중의 유명한 교재에서는 이 상속파트 부터 몇백페이지에 걸쳐서 객체지향 프로그래밍을 다루는데요. 분량이 너무 많아서 이게 기초인가 싶을 정도입니다. 자O의 정석 기초판만 봐도 뭐 답안나오죠. 물론 추천하는 책입니다. 국내에서는 가장 오랫동안 많은 학생들을 가르친 저자의 노하우로 쓰신 교재니까요.
그것보다 제가 주목한 부분은 객체지향이라는 이 밑도 끝도 없는 용어가 사람들을 끌고가는 목적지가 어딘지 궁굼해졌습니다. 무한한 개념을 유한한 인간이 이해하기도 어렵고 무의미하다는 생각이 들때가 있습니다.
자바의 객체지향프로그래밍으로는 이세상의 모든 객체를 다 표현할 수 있는데 과연 그러면 세상을 다 가진것일까?
2000년대 초반에 한국에도 객체지향 프로그래밍이 막 들어오던 시기를 기억합니다. 사람들이 객체지향이라는 방법에 대해 막연한 기대와 무한한 희망을 걸었던 건 아닐까 생각합니다.
물론 2000년대 초반에는 IT버블 붕괴도 있었고 20년이나 지난 지금 굳이 4차산업을 들먹이지 않아도 IT업계야 말로 진정한 도약기를 맞이하고 있습니다.
OOP가 처음 나왔을 때로 돌아가서 막연한 희망감이었다면 현재는 구체화가 아닐까 싶습니다.
희망이 뭐든지 할 수 있다는 기대감이라면, 구체화는 무엇을 해야할지 하지 말아야할지 판단으로도 볼 수 있습니다.
20년 전엔 누가 IT업계의 주인이 될지 몰랐죠? 지금은 GAFA 고 네O버, 카O오죠?
이제 프로그래머들은 컴퓨터의 성능을 압니다. 막연히 기대하지 않고 구체적인 팩트를 취급합니다.
개발자 커뮤니티는 과거 무조건적인 OOP의 찬양에서 조금은 벗어나 있는 듯 합니다. OOP는 장점도 단점도 가지고 있습니다. 이 세상에 항상 빛과 그림자가 있는 것과 같습니다. OOP의 재조명을 볼 때 IT업계가 얼마나 역사가 짧은 분야인지 다시금 생각나게 합니다.
관심있는 분들은 외부참조문서를 읽어 보시길 바랍니다.
미니멀한 접근
기술적인 접근
위에서 설명한 이유로 인하여 자바 상속에 대해서 미니멀한 접근을 하려고 합니다. 쉽게 말해 A와 B는 상속관계이구요, B와 C는 동급이구요. 이런 설명은 하지 않겠습니다.
설령 자바의 OOP를 다윈의 유전학을 바탕으로 설계했다 한들 무한에 대한 학습이란 끝나지 않기 때문에 입문단계에서 이야기하는 것은 무의미합니다.
그런 식으로 객체지향 프로그래밍을 배워서 한 10년 뒤에야 이제 좀 OOP를 할만하겠네. 그래야 할 필요는 없습니다. 특히 IT분야는 빛의 속도로 변하기에 시간의 소중함이 우선합니다. 미래에 가서 ‘그걸 이제야 알았네’ 해도 늦습니다. 이미 늙은거죠.
조금 IT기술에 관심이 있다면 현재의 개발 방식이 바뀔날도 멀지 않았다는 것을 알 겁니다. 그러므로 지금의 기술은 적당히 빼다가 써먹고, 미래에는 퉁쳐서 먹힐만한 사고방식만 가져가면 됩니다.
기술적으로 설명하면 상속은 DNA 상속도 아니고 재산상속도 아닙니다.
클래스 A에 있는 멤버변수와 메소드를 클래스 B에서 다시 정의할 필요 없이 사용하는 겁니다. 따라서 클래스 B의 소스코드를 열어보면 안보이죠. 상속관계로 연결만 되있으니까.
그래도 클래스 A의 모든 것을 사용할 수 있는 겁니다. 특별한 방식으로요.
아래의 예제는 클래스 B가 클래스 A를 상속합니다. 상속받은 클래스 B의 인스턴스는 클래스 A의 모든 것을 물려받습니다. 물론 이때도 상위 클래스 A에서 private 변수에는 접근할 수 없습니다.
public class Main {
public static void main(String[] args) {
myClassB inst1 = new myClassB();
inst1.showInfo();
}
}
class myClassA {
private int id;
private String name;
public myClassA(int id, String name) {
this.id = id;
this.name = name;
}
public void showInfo(){
System.out.println("id = " + id);
System.out.println("name = " + name);
}
}
class myClassB extends myClassA{
private String color;
myClassB(){
super(1001, "Don");
}
}
[실행값]
id = 1001
name = Donprivate 변수들에 접근하려면 getter and setter 를 사용합니다. 아니면 이에 상응하는 public 메소드를 만들어서 가져올 수 있습니다.
구조를 보면 매우 심플합니다. 한가지 B의 생성자에는 super()라는 새로운 물건이 나왔습니다. 이는 this 를 생각해보면 됩니다.
this는 클래스 내에서 인스턴스 자신을 가리키는 키워드였습니다. super() 는 상속도에서 상위 클래스의 생성자를 호출하는 키워드입니다. ( ) 함수연산자를 빼고 사용하면 상위 클래스의 멤버에 접근할 수 있습니다. this 와 super는 상속관계에서 가리키는 대상을 나타내는 것 입니다.
어쨋든 이렇게 보니 클래스 B는 클래스 A에 비해 많이 간단해 보입니다. 이게 외부 라이브러리를 사용하면 진가를 발휘합니다. 그냥 import OO 하고 extends OO 후 new 인스턴스 – 하면 프로그램 뼈대가 생성됩니다..
또 여기서도 extends 라고 말하죠. 우리가 상속이면 뭔가 inherit 인데 영단어를 보세요. 객체지향 프로그래밍의 개념은 상속으로 잡았지만 용어는 extends 즉 기존 클래스를 확장하는 것 입니다.
이 부분에서 한글 번역에 miss 가 있었다고 생각되는데 이 용어를 그대로 extends 로 쓰거나 확장하다로 단어를 바꾸는게 낫지 않을까 싶습니다. 배우는 사람에게 혼동만 늘 뿐입니다.
아마 많은 분들이 느꼈을 겁니다. 이건 상속이 아니라 확장인데, 그런데 그런 문제를 제기하는 것 자체가 피곤하기 때문에 그냥 받아들였을 수 있습니다.
한가지 방법은 한글 문서보다 영문을 많이 보면 그런 생각을 잘 안하게 됩니다. 영어로 사고하는 겁니다. extends 는 상속이 아니라 그냥 extends야.
캠브릿지 사전에 따르면 extends의 뜻은
to add to something in order to make it bigger or longer:
그것을 크게 하거나 길게 하기 위해서 어떤 것을 더하는 것이다.
정말 그말과 같습니다. extends 는 extends 입니다.
일부러 딴지 걸려는 건 아닌데 그냥 아아닌 것 같아서요. 왜일부러 딴지 걸려는 건 아닌데 그냥 아아닌 것 같아서요. 상속이라면서 왜 inherit 이나 succeed 를 쓰지 않았을까? 한글번역은 누가 왜 extends 를 상속이라고 했을까?
뭔가가 맞지 않습니다.
여튼 제가 여기서 주장한다고 누가 알아주는 건 아니겠고 그것을 번역한 이의 의도가 있을 거라 생각합니다만. 그렇다면 그냥 저는 extends 를 to add to something in order to make it bigger or longer 로 받아들이는게 나을 것 같습니다. 영어는 아직 짧으면서도 요새는 사전이 잘나와서 떠듬떠듬 읽으면 되니까요.
요약
잡설이 길어져서 여기서 일단 끓습니다. 총체적으로 좀 어렵다 이런 내용입니다. 논란이 되는 방식이니까 첨단의 기술이라 생각합니다.
아직 완성되지 않았기 때문에 언젠가 진정한 객체지향 기술이 완성되면 지금 우리가 하는 수많은 논쟁들은 과거의 유산이 되겠지만 그럼에도 지금 하는 논의가 있기 때문에 더 나은 기술이 미래로 이어지는 것 입니다.
2021년에도 사람들은 여전히 인공지능이니 자율주행이니 말하지만 그 콘셉트를 세상에 내놓은 것은 100년 전이었다고 합니다. 인공신경만의 한 종류인 퍼셉트론을 고안한 것은 1950년대입니다. 그런데 이제서야 빛을 발하고 있죠.
OOP에 대한 논쟁도 커뮤니티에서는 현재 진행형입니다. 뭐 옛날만큼 사람들이 OOP에 대해 맹신하지도 않고 지금은 파이썬의 절차형 프로그래밍과 동적타이핑을 믹스한 형태가 더 유행을 타고 있죠.
다만 또 자바 언어로 프로그래밍을 할 때는 이런 생각을 하는 겁니다. 과연 OOP가 모든 프로그래밍의 해답인가?
아마 OOP가 처음 나왔을 때 사람들이 기대를 크게 걸었고 지금까지 이어져왔기 때문이 아닐까 생각해봅니다.
이번 챕터는 유난히 사설이 길었습니다. 자바가 곧 OOP의 역사 그 자체라서 한번쯤 설명하고 넘어가야하기 때문이었는데요. 다음 챕터부터는 다시 기술위주로 돌아가겠습니다.
외부참조문서
자바 OOP 논쟁 – Why Are So Many Developers Hating on Object-Oriented Programming? – The New Stack
OOP프로그래밍 – 자바 상속 등 위키 Object-oriented programming
자바 상속 Java – Inheritance – Tutorialspoint