NAME, NAME_TYPE 속성을 이용한 인스턴스 찾기

Vulcan Project에 있는 proxy, mediator 클래스를 보면 NAME, NAME_TYPE이라는 static 상수가 정의되어 있습입니다. 간단히 말하자면 facade를 통해 이들 클래스 객체에 접근하는 방식은 너무 장황한 코드라인을 필요로 하기 때문에 보다 간편한 인스턴스 접근방식을 위해 도입한 속성입니다.

일반적인 접근방식

다음은 PureMVC에서 Proxy(또는 Mediator)인스턴스에 접근하는 일반적인 방법입니다. PureMVC에서 Sample로 제공되는 HistoryPanel의 코드를 살펴보겠습니다.

하지만 이 방법은 Mediator 클래스 이름을 키값으로 등록하여 사용하기 때문에 클래스당 단 하나의 인스턴스만 생성할 때에만 유효한 방법입니다. 따라서 하나의 Proxy(또는 Mediator)클래스가 여러개의 인스턴스를 가질때를 위해 이름에 고유번호를 부여하고 이를 바탕으로 NAME 상수의 값을 설정할 필요가 있습니다.


Multiple 인스턴스 객체에 접근

인스턴스에 접근할때 NAME 문자열을 구성하기 위해서는 필요한 UID를 일일이 알고 있어야 한다는 문제가 생깁니다. 이 문제를 완전히 해소할 수는 없지만 보다 편리한 방법으로 우회할 수는 있습니다.

APPLICATION, DOCUMENT, GRAPHIC 단위로 현재 선택상태(또는 활성화 상태)를 나타내는 각 UID를 기초로하여 인스턴스를 네이밍하고, 인스턴스가 사용되는 용도에 따라 UID관리(인스턴스 관리)를 나누어 관리 합니다. 이를 위해 NAME_TYPE 상수를 도입하였습니다.

이것은 가장 많이 참조되는 현재 Application의 현재 열려있는 Document의 현재 선택된 Graphic 아이템을 찾을때 매우 간단한 방법을 제공합니다.

캡슐화

이 과정은 NameUtils 클래스를 통해 간단히 캡슈화 되었고, 다시 SubSystem클래스(facade)에 의해 메서드로 제공됩니다. 클라이언트 측에서는 한줄만으로 인스턴스에 접근할 수 있게 되었습니다.

물론 현재 활성화 상태가 아닌 객체에 접근할 때에는 UID를 통해 접근해야 합니다.


NAME_TYPE의 결정

NAME 상수와 NAME_TYPE 상수는 클래스 내부에서 static 상수로 정의됩니다. 클래스를 만들때 NAME_TYPE을 설정해 주어야 합니다. NAME_TYPE의 값에는 NameUtils 클래스의 TYPE_APPLICATION, TYPE_DOCUMENT, TYPE_GRAPHIC 값을 설정할 수 있습니다.

어떤 값을 선택할지 결정하기 위해서는 먼저 클래스의 인스턴스가 어느레벨에서 사용되어 지는지를 판단해야 합니다. 예를 들면 Document를 관리하는 Proxy가 있다면 이 Proxy가 사용되는 (레벨)곳은 Application 차원에서 문서를 닫기, 열기 등 Application 차원의 작업에 관여할 것입니다(TYPE_APPLICATION).

각 문서내의 Graphic 아이템을 관리하는 Proxy가 있다면 이 객체는 주로 Document 내부의 데이터로써 관리될 것입니다(TYPE_DOCUMENT).

마찬가지로 Graphic에 관련된 특정 데이터만을 관리하는 - 예를 들면 Graphic 아이템에 따라 다르게 나타나는 컨텍스트 메뉴 데이터를 관리하는 Proxy 클래스가 있다면 이 클래스의 NAME_TYPE값은 TYPE_GRAPHIC값으로 설정되어야 할 것입니다.

가장 중요한 점은 현재 선택 또는 활성화 상태의 UID로 접근 가능한 형태로 클래스가 네이밍되어야 한다는 것입니다. 하지만 여전히 retrieveProxy, retrieveMediator 메서드를 이용하여 접근할 수도 있습니다.


저작자 표시 비영리 변경 금지
신고

'Documents > Startup' 카테고리의 다른 글

NAME, NAME_TYPE 속성을 이용한 인스턴스 찾기  (4) 2010.10.29
Vulcan Project 초기화 과정  (0) 2010.10.25
Vulcan Project 구조  (0) 2010.10.25
PureMVC Framework 수정사항  (4) 2010.10.16
TAG
트랙백 ( 0 )개 , 댓글 ( 4 ) 개가 달렸습니다.

Commentary

댓글을 달아 주세요.

  1. Favicon of http://diebuster.com BlogIcon hika 2010.10.29 23:49 신고  댓글주소  수정/삭제  댓글쓰기

    음 이거 mvc에서 항상 맘에 안드는 부분인데 ^^
    객체간 연결도를 낮추기 위한 결론이 결국 수많은 인간의 못믿을 기억력에 호소하는 거라니..

    보다 진보된 유틸형 함수가 존재해서 IDE신공을 이용하면 충분히 사용할 수 있도록 도와주시는게 좋을지도 ^^

    그나저나..제 프레임웍은 개념이 어려워서 설명자체가 힘들거같기도 한데 ㅋㅋ

    • Favicon of http://vulcan9.tistory.com BlogIcon vulcan 2010.10.31 15:20 신고  댓글주소  수정/삭제

      저도 이부분에서 고민을 좀 했습니다. 좀 어렵더군요
      문서화되지 않으면 의미도 모호해질 뿐만아니라 나중엔 자신조차도 헷깔려할 수 있어서 좀 싫은 부분입니다.
      NameUtils클래스로 약간에 주먹구구식 도움을 받고는 있습니다만 개선되야 하겠죠.
      템플릿 기능같이 자동으로 코드가 생성되면 좋을것 같다는 생각도 해보았습니다.

      근데 히카님 프레임웍이 설명자체가 힘들면 쓰는사람은 어떡합니까요.. 걱정되는데요.ㅎㅎ

  2. Favicon of http://diebuster.com BlogIcon hika 2010.11.01 12:51 신고  댓글주소  수정/삭제  댓글쓰기

    ㅎㅎ lisp나 prolog를 사람들에게 가르칠라 들면 절레거리는 이유는 제어형구조에 쩌들어있기 때문인데 이건 더 확장해서 생각해보면 좀 큰 기업엔 DBA와 개발자가 분리되어있는 이유와도 같죠. 집합, 데이터드리븐 방식의 DBA들이 사용하는 프로시져는 제어형구문으로 사고하는 개발자와 이질적이기 때문에 분리시켜주는 셈입니다.

    제건 구지 언어적인 분류를 나누자면 스토어드프로시저에 가까운데 반대로 얘기하면 제어적언어의 특성을 갖는 클래스부분은 매우 짧게 작성되고 설정파일이 RDB처럼 관계까지 고려한 데이터구조를 짜는 형식입니다.

    따라서 작성후 완성된 결과물의 클래스는 놀랍도록 짧습니다. 아마 as3막코딩으로 최대한 짧게 짜면 천줄이다 라고 예상하시는 코드가 있다면 거의 10줄정도에 작성이 가능하게 됩니다.

    기존 제어구문은 oop의 경우 복잡한 변수제어가 50%, 알고리즘기술 20%, 객체간 통신 30%정도의 비율로 되어있는데, 이중 코드상에서의 변수제어를 5%정도로 없애고 대신 RDB에 해당되는 자료구조를 정교하게 짜도록 합니다.
    또한 객체 간 통신을 호스트 코드를 짜는 개발자에게 맡기지 않고 프레임웍이 대부분 강제로 COC에 따라 해버립니다.
    따라서 남는 조각은 알고리즘인데 lisp처럼 고차함수를 다수 도입하여 고민하고 짜야할 부분이 없는 식입니다.

    그런 이유로 as3코드 자체는 1/100정도로 줄어들게 됩니다. 또한 lisp처럼 다른 패러다임이 아닌 제어형 패러다임도 유지한채라 코드해석에도 전혀 문제가 없습니다.

    문제는 개발자가 RDB를 구성할 수 있는 능력이 있는가라는거죠 ^^
    오히려 데이터모델링을 요구하는게 약점이기도 한데, 일반 사용자를 위해 만든게 아니라 회사의 개발프로세스를 개선하고자 만든거라, 어려운 데이터 구조는 제가 짜고 as부분은 짧게 할거없이 찍어내고, 기획자나 디자이너는 완성된 설정파일에 수치작업을 해간다라는 형태인거죠 ^^;

    애시당초 대중성은 기대하지 않고 있는 생산성 중심의 프레임웍...그래서 현재 프레임웍은 완성되었으나 공개를 해야할지를 생각중입니다.

    • Favicon of http://vulcan9.tistory.com BlogIcon vulcan 2010.11.01 14:52 신고  댓글주소  수정/삭제

      ㅎㅎ 히카님 글은 역시 많은걸 검색하게 만듭니다. 블로그를 통해 밝히셨듯이 대부분의 복잡한 연산은 내부적으로 숨기고 사용자는 이미 built-in된 함수와 이미 의도된(?) 전체 프로세싱에서 약간의 설정작업 정도의 작업만으로도 결과물이 산출될수 있다는 건데 - 일단 이건 사용하기 쉽다는말이겠지요. 근데 프레임웍을 제대로 좀 써볼려면 RDB를 설계할 능력자가 꼭 있어야 된다는 점에 고민이 많으신것 같네요.
      프레임웍을 공개하는것은 단순히 유틸을 공개 하는것과는 다르게 개발단계에서부터 배포하기까지 정말 많은 고민을 하게 하는것 같네요. IDE차원에서 도움을 받을 수 있는 형태로 배포가 된다면 그나마 나을텐데 그만큼에 댓가가 또 따르겠죠.
      저는 오픈하기 전에 이거 나만 알아먹는 날코딩을 갖고 프레임웍 오픈한다고 떠들어도 될라나 하는 이런 고민 참 많이 했는데요. 오픈하고 나니까 그런 고민보다는 코드를 한번 더 쳐다보게 되더라고요.ㅎㅎ
      제가 위에 써놓으신 히카님 글에 나온 단어에 절반이 무슨뜻인지도 몰라도 얘기가 통하는 것처럼 전 제 코드를 사용할 사람들에 수준에 대해서는 더이상 고민하지 않습니다. 상대적인거니까요. 아마 히카님 작업 공개하면 구조를 한번 공부해 보고 싶기도 합니다.^^

Add a Comment

comment에 대한 답변글은 해당 글상자에 있는 "R"(reply)버튼을 클릭하여 작성해 주시기 바랍니다.

티스토리 툴바