Aspected Oriented Programming(AOP)을 가장 잘 지원하고 있는 언어를 꼽으라면, 숨도 쉬지않고 Java를 선택할 수 있겠다. Java의 경우에는 주로, VM코드를 직접 수정하는 방식으로 구현하는 모양인데, C++에서 기계어를 고치고 있을 수는 없는 것 아닌가.. 상상만 해도 우울하다.
더 보기 “C++ Native AOP의 가능성.”
[월:] 2007년 04월
표준의 규모. 작은 것이 맞는가? 큰 것이 맞는가?
한국MS의 어줍잖은 변증법 via Channy’s blog
당신은 무엇 때문에 기술표준을 따르나 via 서명덕기자의 人터넷세상
이 두가지 포스팅을 읽던 중, 눈에 들어온 것이 하나 있었다. 한국MS의 ODF(Open Document Format)에 한 반론중, OpenXML은 “크지만 안정적” 이고, ODF는 “간결하지만 지속적으로 규모가 증가” 한다는 이야기인데, 표준의 규모에 대한 생각이 문득 들었다.
물론, 무엇에 관한 표준인지, 무엇을 담고 있는 표준인지가 중요하겠지만, 내 생각에 표준은 작고 간결해야한다. 표준이 크고 복잡하면 복잡할 수록 구현은 힘들어지고, 고려할 사항이 복잡해지기 때문이다. 그리고, 복잡할 수록 재사용이 난감해지는 경향이 있다. 작고 간결한 여러 종류의 (다른 기능적인) 표준이 존재하고 서로 의존적인 관계를 갖고 있다고 하면, 원하는 결과물을 얻기 위해 표준을 섞는 일이 가능해진다. 다른 표준에 의존할 수 있는 것은 의존하는 것이 맞다. 예를 들어, XHTML에 벡터그래픽에 대한 요구사항이 커졌다고 해서, XHTML 3.0에 벡터그래픽요소를 정의할 필요는 없다. XHTML 1.0문서와 SVG문서를 섞어서 사용하는 것만으로 충분히 구현이 가능하기 때문이다.
작고 간결한 표준은, 해당 표준을 준수하는 처리기processor 나 구현체implementation를 만드는데 필요한 리소스를 줄이는 데에도 큰 역할을 할 수 있다. 그리고, 리소스가 줄어든다고 하는 것은, 해당 표준에 대한 오픈소스 처리기/구현체의 증가를 의미하기도 하며, 좋은 참조구현reference implementation의 등장을 의미한다. XML이 지금보다 훨씬 복잡하고 잡다한 내용을 전부 담고있는 표준이었다고 생각해보자. 지금처럼 히트칠 수 는 없었을 것이다.
OOP(객체 지향 프로그래밍: Object Oriented Programming)적인 관점에서 바라본다면, 표준은 일종의 클래스class라고 할 수 있다. 생각해보자, 거대하면서 모든 일을 혼자 다 해치우는 클래스 하나가 좋은지, 자기 할일만 제대로 해내는 (그리고 변경하기 쉬운) 작은 클래스 여럿으로 구성되는 것이 좋은지. 답은 명확하다. 할 수 있는 한, 클래스는 작아야한다. 표준도 마찬가지다. 가능한 작아야한다. 원하는 기능이 다른 표준에 정의되어 있다면, 가져다 쓰는 것이 맞다. 굳이 여러번 정의할 필요는 없는거다.
표준. 작고 간결해야 표준으로서 가치를 갖게 되리라 믿는다. 정의가 존재한다면…
ps. 무려 1달하고도 9일만의 포스팅.. 덜덜.