[AS3 강좌] 아키텍트를 위한 Class 를 이해해보자.

흔히들 클래스는

사전적인 의미인 "재사용" 으로 이해하기 쉽다.

게다가 태생적으로 플래시로 클래스를 입문한 사람들은

자바나 C 진영에서 거의 기본으로 배우게 되는 클래스에 대한 개념이

많이 부족한게 사실이다.

하지만 ECMA 를 따르는 AS3.0 이 나오면서

자바나 C 에서 활용되던 여러가지 방법론, 개발환경들을

많이 마주치게 된다.

특히나 플렉스로만 가능하던 대규모 어플리케이션도

플래시 IDE 로도 충분히 소화할 수 있는 방법들이 연구되면서

(IDE : Integrated Development Enviroment 통합 개발 환경 )

OOP의 기본중의 기본인 클래스에 대한 정확한 개념을 탑재할 필요가 있다.

사설을 먼저 풀자면

필자 역시도 2.0때는 클래스에 "클"자도 몰랐고

3.0을 시작하면 "아~" 하면서 배운 케이스다.

아직 그때의 시행착오들이 기억에 남아서인지

지금 되짚어보면서 글을 남기는게 좋을거 같은 생각에서 정리해본다.



1. 사전적 의미

Class 는 재사용이 가능하고 확장이 가능한 오브젝트.

맞는지 모르겠지만 키워드는 "재사용"과 "확장" 이었던거 같다.

클래스는 언제 어느때건 재사용이 가능해야하며

extends 키워드를 통하여 확장이 가능하여야 한다.

물론 final 이면 얘기가 다르지만...


2. OOP 의 시각에서 본 의미

OOP 에서 바라보자면 클래스는 하나의 뚜렷한 "역할" 이다.

하나의 클래스는 하나의 역할로 정의될 수 있어야하며

자신의 역할을 벗어나는 기능은 클래스내에 존재해서는 안된다.

( 어떤 저자는 멤버변수를 참조하지 않는 메소드는 클래스내에 있어서는 안된다라고 까지 했다. )

그 내부에서 어떻게 돌아가는지는 절대 외부로 노출되어서는 안되며

외부에의해서 조작되어서도 안된다.

또 반드시 기능에 필요한 값은 외부로부터 전달받아 결과값만을 되돌려줘야 한다.

( 바로 참조하면 안된다는 뜻도 포함한다. 값을 전달받아야한다. )

즉 자동차에 비유하자면

핸들은 돌아간 정도를 바퀴에 전달만 해주면 될뿐

왼쪽 바퀴를 얼마만큼 오른쪽 바퀴를 얼만큼 움직일지 계산해서 알려주는 친절함을 발휘할 필요가 전혀 없다는 이야기다.

또한 핸들이 직접 바퀴를 돌려서도 안된다. (바퀴를 돌리는 역할은 따로 있기 때문)

만약 부드러운 코너링을 위해 안쪽으로 도는 바퀴가 조금 더 돌아가는 시스템이라고 할때

그 핸들을 티코에 사용한다면

자동차는 제대로 코너링 할 수 없을것이다.

핸들은 운전자가 핸들을 얼만큼 돌렸는지만 측정하면 된다.

어느바퀴가 어느정도 돌아갈지는 바퀴가 담당하면 될일이다.

필자가 주로 만드는 FLV 플레이어에서

Screen 을 담당하는 클래스는 영상이 끝났던 돌고 있건 에러가 났던

그저 Stream 객체에서 화면만 받아다가 뿌려주면 땡이다.

Screen 객체가 Stream 이 오류가 났는지 안났는지 알필요 없다.



자 이쯤에서 입장을 바꿔서

Screen 은 자신이 화면을 출력하기 위한 기능을 충실히 수행해야한다.

즉 사이즈를 변경할때 16:9 비율을 유지하는 기능이 있다면

Screen 의 부모인 Player 가 비율을 계산해서 width, height 를 조절해주는게 아니라

width, height 는 그냥 막 주고

비율을 유지해라라는 명령만 내려주면

Screen 객체가 알아서 비율을 유지해야한다는 이야기다.

가뜩이나 할일 많은 Player 가 화면 비율까지 조절해야한다면

얼마나 스트레스 받겠는가?

이렇게 Screen 이 자신의 역할을 충실히 한다면

Player 는 그만큼 할일이 줄어들기 때문에

상대적으로 다른 역할에 더 충실할 수 있는 여유가 생긴다.

흔히 하는 실수들이

Controller 에서 Screen 을 직접 참조해서

Controller 와 Screen 이 딱 붙어서

떨어지지도 않고;; 중간에 뭘 삽입할수도 없고;;

난감한 상황이 벌어지는것이다.



이처럼 자신의 역할을 충실히 하는 클래스야 말로

OOP 의 관점에서보는 "역할" 인 것이다.



OOP 의 기본인 "역할"에 충실해야지만

어떤 역할을 어떻게 분배할지를 결정하는 디자인 패턴,

어떤 역할 고르게 재분배할지를 판단하는 리팩터링,

어떤 역할을 중하게 수행하며 어떤 역할은 비중을 작게 하는 등의 SOAP ( 비약이라고 한다면 할 말 없다 ㅎㅎ )

이런 개념들이 올바르게 이해될 수 있을것이다.

이런것이 모여서 커다란 하나의 소프트웨어가 되었을때 우리는 그 안에서 아키텍트라는 것을 구경할 수 있는 것이다.