KINETICROAD | 하루하루가 새로운 세상

ActionScript 3.0을 시작한지 벌써 1년 9개월이 됐다.

3.0이 라이터로 불을 붙이는 거라면 2.0은 부싯돌로 불을 붙이는 것과 같은 효과라고 생각한다.

(물론 모바일에 들어가는 FlashLite는 다른 이야기다.)

3.0으로 OOP 개념을 공부하며 궁금했던 것은 인터페이스 클래스다.

인터페이스 클래스가 왜 필요하지?

요새 프로젝트를 진행하다 보니 나도 모르게 인터페이스 클래스를 사용하고 있었다.

그도 그럴 것이 어떤 구조체가 대입되어 들어오게 되던 커스텀된 컨포넌트에 전달되어야하는 필수 조건들이 있기 때문이었다.

그래서 반드시 구현되어야 하는 프로퍼티, 메서드들이 필요했다.

그렇지 않으면 필수요소를 전달받지 못해 프로그램이 오작동 할 수 있기 때문이었다.

그래서 인터페이스 클래스를 기본적으로 정의한 후 그 클래스 형이 아니면 인자로 받지 못하게끔 제동장치를 걸어놓았다.


package classes.core
{
public interface IListItem
{
	function set location(value:String):void
	function get location():String

	function set dataObj(value:Object):void
	function get dataObj():Object
}
}

위와 같이 인터페이스 클래스를 만들어 놓으면 아래와 같이 구현한다.


package classes.controls
{
import classes.core.IListItem;

import mx.core.UIComponent;

public class MyControl extends UIComponent implements IListItem
{
	public function MyControl():void
	{
		super();
	}

	//-------------------------------
	//  interface 구현
	//-------------------------------
	private var _location:String = null;

	public function set location(value:String):void
	{
		_location = value;
	}

	public function get location():String
	{
		reuturn _location;
	}

	private var _dataObj:Object;

	public function set dataObj(value:Object):void
	{
		_dataObj = value;
	}

	public function get dataObj():Object
	{
		return _dataObj;
	}
}
}

위와 같이 인터페이스를 구현해 놓게 되면 클래스 사용자는 위와 같은 프로퍼티를 기본적으로 갖고 있게 된다.

물론 클래스를 이용하기 위한 필수 조건을 반드시 포함하기 때문에 실수할 염려와 디버깅 횟수를 줄일 수 있다는 장점이 있지만 이것 만으로는 약간 모자란 감이 있다.

실수는 누구나 하는 것이지만 조금만 신경을 쓴다면 이런건 문제가 아닐 수 있기 때문이다.

(물론 클래스 개체가 늘어나고 코드가 한없이 복잡해 진다면 당연히 문제가 되긴 하겠지만.)

하지만 예를 들어 위의 IListItem 인터페이스 클래스를 구현한 서로 다른 클래스가 있다고 가정해보자.

위에 있는 MyControl라는 클래스와 별개의 클래스인 MyControl2라는 클래스가 있고 MyComponent2 라는 클래스는 Sprite를 확장해 만들었다고 가정하면 그 둘의 공통점은 서로 같은 인터페이스를 구현한것 밖에 안된다. 하지만 아래와 같은 예제에서 그 인터페이스가 유용하게 사용된다는 점을 알 수 있다.


package classes.data
{
import classes.core.IListItem;
import classes.controls. MyControl;
import classes.controls. MyControl2;

import mx.core.UIComponent;

public class ExampleClass extends UIComponent
{
	public function ExampleClass()
	{
		super();
	}

	private var myControl:MyControl = new MyControl();
	private var myControl2:MyControl2 = new MyControl2();

	public function sampleMethod(control:IListItem):void
	{
		trace(control.location);
	}

	private function callSampleMethod():void
	{
		sampleMethod(myControl);
		sampleMethod(myControl2);

                trace(IListItem(myControl).location);
                trace(IListItem(myControl2).location);
	}
}
}

위와 같이 IListItem을 인터페이스 클래스로 구현된 클래스들은 아무리 서로 다른 클래스라도 IListItem 인터페이스 클래스로 캐스팅이 가능하다. 이 이야기는 IListItem 클래스가 구현된 모든 클래스 및 자식 클래스들도 모두 IListItem으로 캐스팅 할 수 있으며 여기에서 발생하는 장점은 좀더 유연한 코드를 작성 할 수 있다는 것이다.

(확장성이 더 좋다고 표현하는게 맞을지 모르겠지만 적어도 "액션스크립트 3.0 디자인패턴"이라는 책에서는 그렇게 설명하고 있다;;)

커스텀 컨포넌트를 만들다 보면 항상 고민하는 것이 사용자가 어떤 클래스를 넣어서 사용할지 모르는 불확실성에 대응하는 코드를 구성하는 것이었다. 이런 인터페이스 클래스를 이용함으로써 커스텀 컨포넌트를 만드는데 조금 더 유연한 코드를 갖출 수 있다면 더 효율적으로 코딩할 수 있을 거라고 생각한다.