상속… 무슨 소리야?

상 속… 참 단어 애매합니다. 분명 의미를 생각하면 맞는데, 이게 좀 거시기 한게… 딱 "상속" 이란 단어를 생각했을때 뭐가 안떠오르거든요… (진짜 가끔씩은 프로그래밍 용어들을 카피라이터들 한 2~30 명 모아놓고 다 싹 정리해버렸으면 좋겠다는 생각이 들죠… 뭐 씨… 존내 거창하기만 하고, 연상력도 없는 알맹이 없는 단어들…)

MovieClip 의 상속 관계

상속이 뭔지 알아보기 위해서 좀 무식한 짓거리를 해보도록 하겠습니다. 

큰 크림은 http://ssen.name/develop/as/grand/Grand1.png 로 보세요.

MovieClip 부터 Object 까지의 상속관계를 몽땅 다 캡쳐 떴습니다. 상속은 이것만 봐도 됩니다. 요것만 이해해도 상속이 뭔지는 깜샷을 날릴수 있습니다. 뭐 있나요… 개발자처럼 뇌에서 상상할 수 없으면, 눈으로 보면 되죠. 초보에겐 눈알이 있다! 좋습니다… 눈으로 확인하세요. 상속이 뭔지 깜샷 날릴수 있습니다.

대충 봐도 알수 있다시피… Object 에서 DisplayObject 를 거쳐, Sprite 를 넘어, MovieClip 까지 진화하는 과정을 주욱~ 볼 수 있습니다. 대충 설명해 볼까요?

Object 는 일단 ActionScript 의 최하 기본형 입니다.

EventDispatcher 는 Event 를 사용할 수 있도록 진화됩니다.

DisplayObject 는 화면에 표시되는 기능을 추가로 가지게 됩니다. 3D 게임의 렌더링 기능을 가지고 있죠.

InteractiveObject 는 마우스, 키보드 등의 인터렉티브 구현이 추가됩니다.

DisplayObjectContainer 는 우리가 흔히 이야기하는, "무비클립 안의 무비클립" 을 가능하게 해주는 다중구조를 가지게 되죠.

그리고, 이제 Sprite 라는 우리가 사용하게될 기본 화면출력 기능으로 진화가 됩니다.

마지막으로 Sprite 에 frame 기능을 넣어서 MovieClip 이 완성되죠.

여기서 MovieClip 은 Sprite 를 상속 받아서 만들었다… 라고 이야기 합니다.

이게 다에요… ㅡ ㄴ ㅡa 이게 상속 입니다.

이 렇게 원시형의 기능을 간직한채로 계속해서 뭔가 기능을 추가하는 것이 상속 입니다. 보통 초보들에게 교육을 할때 쉽게 설명하기 위해서 "부모와 자식" 의 관계를 이야기 하지만, 사실 좀 애매하죠… "부모와 자식 관계 이론" 으로는 완벽한 이해가 어렵습니다. 예전 시간에 잠깐 이야기 했었는데 이런 관계는 진화론으로 설명하는 것이 좀 더 쉽습니다.

인간 --> 영장류 --> 포유류 --> 척추동물 --> 생물

뭐 이런식의 공통화가 오히려 더 설명하기 쉽죠. 여기서 생선들의 경우엔 척추동물을 상속받겠죠. 고양이 같은 경우엔 포유류에서 상속을 받을 수 있겠구요. 흔하게 우리가 사용하는 이런 생물학적 분류는 상속관계를 정리해서 좀 더 알기 쉽게 정리한 것입니다. (이런 분류 자체가 자연의 진실을 완벽히 설명하는 것이 아니라, 생물학적 근거와 인간의 편의에 의해서 만들어진 것이죠… 이런 근거에 의해서 생각하다가 가끔 애매한 생물 하나 튀어나오면 과학자들 입싸움이 시작됩니다...) 프로그래밍은 "아예 처음부터 만드는 디지털" 이기 때문에, 보통 하위에서 상위로 올라가는 사고방식을 가지지만, "자연의 역학을 분석해서 만드는 아날로그" 적 사고방식에서는 이미 모든것이 완성되어 있는 자연이기 때문에 상위의 공통점을 모아서 하위로 분류하는 내려가는 사고방식을 가지죠.

프 로그래머들이야 이미 익숙해진 방식이라서 "하위에서 상위로 올라가는 사고" 를 쉽게 가지지만, 보통의 인간이 가지는 사고방식은 "아날로그적인 상위에서 공통점을 모아서 하위로 내리는" 기준에 더 익숙하기 때문에, 실제 작업 상황에서도 "공통점을 모아서 하위로 내리는" 방식이 좀 더 자연스러운 편입니다. 괜히 개발자 흉내낸답시고 "하위에서 설계해서 상위로 가면서 완성하는" 방식을 따라하려다 피보는 경우가 많거든요. "공통점을 모아 내리고", "설계해서 위에서 구현하고" 하는 방법은 기능의 상속구조를 만드는데 둘 다 쓰이는 것이긴 하지만, 일단 초보시절에는 좀 몸이 고생하더라도 "일단 만들고, 공통점이 생기면 모아서 내리는" 방식을 사용하는 것이 좋습니다. 거기서 좀 감이 생기면 이제 "설계해서 위에서 구현하는" 방식을 서서히 갖춰가면 되겠구요.

아 그리고, 한국인의 자연스러운 먼저-->이후 의 순서가 아니라, 서양인들의 이후-->먼저 방식이 갖춰지는 경우가 있는데… 그런것을 납득하고 가는것이 좋습니다. 이게… 양넘들이 많든거잖아요…;;; 공부하다보면 가끔 "에…?" 라는 경우가 분명 생길겁니다.

인간의 생물적 분류를 코드로 풀어보면

일단 생물이라는 원시형을 만듭니다. 호흡하고, 먹고, 죽는건 어떤 생물이든 동일한 것이죠…

그리고, 등뼈동물의 분류를 원시 Organism 을 상속받아 만듭니다. (뭐 생물학적 사실을 거의 무시한 예제이긴 하지만, 걍 일단 이해하고 봐주세요… "풋… 넌 생물시간에 딱지치기 했니?" 뭐 이런말 하지 말구요…)

class ClassName extends XXX 는 "ClassName class 는 XXX 를 상속받는다" 라는 선업 입니다. 누구한테 말하나요? 인간? 아니죠~ 컴퓨터? 맞습니다~

생물(Organism) 을 상속받아 만든 척추동물(Vertebrate) 이므로, "호흡하고", "먹고", "죽는" 기능은 그대로 가지고 있습니다.

등뼈동물을 상속받아서 포유류를 만듭니다. 포유류의 특징인 젖먹이기가 있습니다. 여기서 번식행위는 곤충도 하는 것이기 때문에 하위로 내려야 하는거겠죠... 

영장류 입니다… ㅡ ㄴ ㅡ;;; 검색을 해서 특성을 찾으려고 하는데, 좀 표현하기 어려운 것들이 많네요.

대망의 인류 입니다… 영장류를 상속받아서 만듭니다… 막상 인간에 대해 생각해 보니깐, 돈버는거 말고 생물이랑 뭔 차이가 있는지 잘 모르겠네요…;;;

하 여튼… 이렇게 해서 생물부터 시작해서, 인류까지 상속구조를 만들어 보았습니다. 이런 예제가 딱히 실제 ActionScript 개발에 적용되는것은 아니지만, 일단 개념정리를 하자면, 이런식이 되는거죠. 중간에 나온 번식행위(왠지 쓰기 민망하군…;;;)의 경우와 같이 class 를 만들다가 "이건 하위레벨의 공통점이 존재한다" 싶은것은 기능을 들어내서 내려보내면 됩니다.

ActionScript 3.0 에서의 상속

ActionScript2 에서도 class 는 존재했고, 당연히 상속구조 역시 존재했지만, ActionScript 3.0 에서는 그 중요도가 한층 커졌습니다. 예를 들어서 "달력의 기능을 가졌지만, 디자인은 달라야 할 경우" 같을때, 달력에 대한 기능은 하부구현을 하고, 디자인 레벨의 것은 상위에서 상속받은 것들로 구현하는 것이 가능하죠. 음… 예전에도 가능했던 것이지만, 좀 더 쉽고, 편하게 만들수 있도록 기능이 강화되었다고 할까요?

이 런 상속성에 대한 중요도는 곧 "고급개발자" 와 "타분야와 개발을 같이 병행하는 서비스 개발자" 의 팀플레이가 가능해지는 이유가 되기도 합니다. "고급개발자" 가 사용될 수 있는 원시기능들을 모두 만든 다음에 "이거 상속받아서 이렇게 하면 되요…" 라고 말하면, "서비스 개발자"의 경우엔 어려운 알고리즘을 손댈 필요없이 그냥 상속 받아서 서비스에 맞게 만들면 되는거거든요. 모든 개발자가 다 "열라 어려운 알고리즘을 척척 만들어내야만 좋은" 그런 시절은 이제 끝났다는 거죠… 고급 인력이라고 해서, 꼭 존내 잘짜야만 하는건 아니라는거죠. 그냥 알고리즘이나 설계적 지식이 뛰어난 개발자가 하부구현을 하고, 그런면은 잘 모르지만, 서비스적인 개념이 뛰어난 개발자는 그걸 받아서 서비스에 맞게 만들고… 이게 좀 더 쉽고, 간단해진 언어가 ActionScript 3.0 입니다.

언 어의 구조적 면이 받춰주기 때문에 2.0 에서는 "존내 잘짜야만 고급인력" 이었던게, 3.0 에서는 "조금 못짜도, 자기 역할을 잘해내는 사람 역시 고급인력" 이라는 공식이 성립될 수 있는거죠. 구지 또 이야기하자면… "프로그래밍 조금 할 줄 아는 디자이너" 도 고급개발자 라는 이름을 달 수 있다는 이야기가 됩니다. 그가 있음으로 인해서 개발자가 짊어져야 하는 퍼블리싱, 디자인적 면의 부담을 덜어주고, 그로 인해 전체적인 팀의 성능이 올라간다면… 그게 고급인력 인거죠.

꼭 한 분야의 마스터만이 "고급" 이라는 수식어를 다는것은 아닙니다. 기술은 인간을 위해 발전하고, 꼭 한분야의 기술적인 마스터링만이 "인간으로서 내가 하고 싶은 일" 에 부합되진 않기 때문에, 그것을 타파할 방향으로 발전한다는 이야기가 되기 때문이죠. 기술 발전에 관심을 가져야 하는 이유중에 하나는 "자신의 일하는 인간 으로서의 인권" 을 찾는데 관심을 가지는 것과 같습니다. (뭐 가끔 "뭐야 ㅆㅂ 이건… ㅜ ㄴ ㅜ" 이라는 식으로 발전하기도 하지만…;;;)

음… 그리고, 일단 ActionScript 2.0 보다 class의 숫자가 "잔인할" 정도로 많아져서, 2.0 개발하던 사람이 3.0 레퍼런스를 열면, "헉!" 소리를 먼저 내뱉게 됩니다. 하지만, 추가된 기능 몇가지를 빼놓고는 사실 실제 사용되는 것들은 2.0 과 개수 차이가 크지 않습니다. 이렇게 상속구조를 통해서 기능들을 분리하다 보니깐 늘어난 것 뿐이지… 실제 사용되는 것들의 개수는 2.0 과 비슷하죠. 아니… 오히려 공통적이던 기능들을 하나로 뭉쳐버리면서 2.0 에서 사용되던 것들만 따져보면 더 적어졌습니다. 작업해야할 것이 늘어나서 사용할 게 많아진 것 뿐이지… 2.0 의 작업을 3.0 으로 고대로 옮긴다 하면, 오히려 사용되는 것이 더 적어지기도 합니다. 그리고, 무엇보다 기능이 뚜렷하게 구분되기 때문에 상식적으로 납득이 가므로 이해하기 쉽죠. 2.0 을 배우다보면 인간의 자연스러운 사고에 기준해서 상식적으로 납득이 안되는 불합리한 점이 많고, 그런점이 이해도를 떨어뜨린다는 것을 생각했을때 결국 3.0 이 더 쉽다는 이야기가 되기도 합니다.

상속과 같은 프로그래밍 개념에의 접근

많 은 프로그래밍 초보들이 오해하는 것 중 하나가… "기계적이면 대단하다" 라는 것인데… 사실 프로그래밍은 굉장히 "인간의 사고력에 가까운" 것을 목표로 발전중입니다. C, C++, 포트란 같은 파워풀한 것들을 "저급언어" 라고 부르고, ActionScript, ruby 같은 것들을 "고급언어" 라고 부르는 것은, "기계의 말에 더 가까운 프로그래밍 언어보다 인간의 말에 더 가까운 프로그래밍 언어가 더 고급이다" 라는 뜻이죠… 뭐… 아직은 컴퓨터가 느리고, 고급언어들의 안정성이나 검증횟수 등이 문제가 되기 때문에 저급언어에 대한 가치가 훨씬 더 높은 편이지만, 웹프로그래밍 같은 경우에는 그 성능에 대한 요구가 적은 편이기 때문에, 고급언어들의 수요가 점점 늘어나는 추세입니다.

상속의 경우에도 사실 저급언어들 보다는 고급언어들에서 더 그 비중을 높이는 "자연스러운 인간의 사고력" 에 기준한 방식입니다. 어렵고 복잡하게 보이지만, 사실은 인간이 평범하게 상상할 수 있는 방식이라는 거죠…

의 외로 프로그래밍을 배우다보면 이렇게 "인간스러운 방식" 을 따르고, 또 그런 방식의 추구를 위해서 발전해 나가는 모습을 많이 볼 수 있습니다. ActionScript 3.0 도 구지 이야기 하자면… 좀 더 생각하는데로 짤 수 있습니다. 기계적 룰에 따르지만, 간단하던 2.0 보다 좀 복잡하고 까다롭지만 익숙해지면 더 쉬운 3.0 이란 말이 나오는 이유도, 좀 더 "내가 생각하는데로 만들면 그 결과가 나오는" 인간의 사고력을 자연스럽게 따르는 언어이기 때문이죠… 의외로 3.0 이 더 쉽습니다. ㅡ ㄴ ㅡa

출처: ssen님의 레시피

http://ssen.name/zb/2185