Composite Model은 물론 어디나 쓰이고 편리한 것으로 생각되지만,
특성을 자주 지워버리는 문제가 있다.
보통 glype와 같은 곳에서 부터 발전해 나아가는 모습을 보고 있으면,
물론 처음에는 하나 하나의 단위를 부여하면서 하나의 멋지게 정리된 분류를 생성해 낸다.
그렇지만, 나중에 그것들이 하나 하나 발전하게 되면서 제약적인 부분이 생긴다.
특히 Modeling에 익숙하지 않은 개발자가 사용하게 되면,
발에 맞지 앉는 구두를 신은 것 처럼 계속해서 거슬리는 규칙들을 달고가게 되고,
수많은 메모리를 낭비한 후에 버리고 마는 것이다.
잠시 머리속에 web programing에서 controller와 component를 하나가 되게 개발을 하면 어떨까 생각해 보았다.
물론, ActionScript의 경우(라기보다는 flash등), 처음부터 movie와 sprite등이 모두 compositable하게 만들어 졌고, 잘 만들어진 계층적 구조를 가진 object들이 되었긴 하다.
하지만, 개인이 이런 클래스들을 당장의 편의성 때문에 시도해 보면, 메모리나 지나친 단계가 많아지는 composite object를 적절히 처리할 수 있을지 의문이다.
물론, 의문이 생겼으니 시도해 보는 것이 순서이긴 하겠지만 말이다.
현재, component가 요구하는 사항은 post나 get 방식의 데이터이다.
controller가 요구하는 것은 현재 없다. Front Controller만이 URL을 요구하고 있다.
그러므로, controller 가 Front Controller와 상당히 분리된다면,
contoller는 그대로 component가 될 수 있다.
다만 여러가지 이유로 불편함을 초래할 수 있다.
그것은 일단 controller로서는 의미없는 hooking을 하게 되는 점이 있고,
component로서는 의미없는 Controller라는 이름을 달고 있어야 한다는 것이다.
(물론 반대로 Controller라는 이름을 없애도 되지만, Front를 건드려야 되는 부담이 있다.)
하지만, 이 둘을 통합하면 component와 controller의 구분 없이 제작 후 가져다 붙이기가 가능해 진다.
무엇보다 테스트를 따로이 controller에서 만들어서 할 필요가 없어진다.
(하지만 여전히 test는 만들어야 할테니 그리 큰 장점은 되지 않는다.)
그렇다면 시도해 볼 것은 단순하다.
아직 이름이 비어있는 Component시리즈를 만들면 되는 것이다.
빠르게 난관에 봉착해야만 포기할 수 있을텐데... 하는 생각을 해 본다.
댓글 없음:
댓글 쓰기