XML 다루기

http://koojunho.textcube.com/22

http://koojunho.textcube.com/38

http://koojunho.textcube.com/55

 

몇 번의 고민을 통해 XML을 직접 데이터로 사용하기 보다는 XML의 엘리먼트들을 잘 표현하는 Object로 바꿔주고 컬렉션을 통해 사용하는 것이 좋을 것 같다는 결론을 내렸다. (물론 여전히 상황따라 다를 수 있다는 전제를 깐다. ㅎ)

 

XML만을 사용하는 경우 XML을 데이터로 주고받는 상황에서 문제가 많이 생긴다. 어떤 XML 엘리먼트건 XML로 받을 수 있기 때문에 해당 값이 내가 받고자 하는 엘리먼트인지 아닌지를 판단하는 문제는 런타임으로 넘어가게 된다. XML이 수정되는 경우라도 컴파일 타임에는 아무런 문제를 일으키지 않기 때문에 모든 문제를 런타임으로 넘기게 된다. 문제가 런타임으로 넘어가면 프로그램의 해당 부분을 실행하기 전까지 문제가 있는지 아닌지 알 수 없게된다.

 

Object라고 해서 데이터가 수정될 때 아무런 작업이 필요 없는 것은 아니다. XML을 파싱해서 객체로 만들어 주는 과정과 자료구조를 만들어 주는 과정이 필요하다. 게다가 검색기능은 E4X, XPath 등에 비해 훨씬 귀찮다. 그러나 데이터가 바뀌고 클래스를 바꾸면 해당 값을 사용하는 모든 클래스들이 반응하게 된다. XML에서 특정 엘리먼트의 데이터를 다루는 방법이 바뀔경우 캡슐화된 클래스 내에서 처리방법만 바꿔주면 그 클래스를 사용하는 모든 클라이언트 코드가 자동으로 바뀌는 셈이다.

 

그렇지만 XML을 클래스로 만드는 것도 일은 일이다. 그래서 유닛테스트 프레임워크를 사용해서 완성된 XML을 기반으로 클래스를 만들면서 테스트를 하면 구현이 필요한 클래스의 나머지 일부가 어떤 것인지를 에러로 보여주는 클래스를 구현했다. 만약 내가 어떤 엘리먼트의 자식 엘리먼트로 <title />을 추가하고 실행을 했다면, 알 수 없는 title이라는 존재를 인식한 객체가 예외를 발생시키는 구조다. AS3.0에서 this[elementName] 으로 접근하여 값을 집어넣게 하는 방식으로 처리했다. this객체가 dynamic 클래스의 인스턴스는 아니기 때문에 동적으로 값을 넣을 수 없으면 예외를 던지는 것이다.

 

직접 XML을 클래스로 바꾸는 작업도 같이 진행했는데 처음에는 더뎌 보였지만 기반 클래스가 갖춰지자 테스트에 의존해서 클래스를 만들어 내는 쪽이 더 빨리 끝났다. 별로 머리 쓸 일이 없게 해준다.

 

엘리먼트마다 클래스가 생겨서 해당 엘리먼트 또는 자식 엘리먼트들을 처리하기 위한 기능들을 추가할 수 있게 됐다. 예를 들어 날짜를 갖고있는 XML이 있다면 XML로 접근했을 때 텍스트일 뿐이고 나중에 클라이언트 코드에서 해당 XML을 Date 클래스 등으로 변환해 주어야 한다. 클래스로 구현이 되어 있는 경우는 미리 그 작업을 베이스 코드에서 해주기 때문에 편해 보인다.

 

물론 XML을 OOP 구조로 치환 했을때 데이터를 제대로 표현했다고 하기에는 무리가 있다. 객체를 사용하는 게 더 좋다고 결론을 내렸다지만 XML을 객체로 치환하는 게 중요한 게 아니라 XML로 표현 된 데이터를 객체로 제대로 표현하는 게 더 중요하다. 사람의 고민이 필요한 부분에선 이 클래스들도 영 쓸모가 없다. 그래서 중요한 것은 만드려는 게 무엇인가를 먼저 봐야 하는 거고, 그 보다 더 좋은건 XML 정의하는 과정에도 참여하는 게 더 좋았을 텐데, 아직 설명은 못들었고 주말엔 쉬어야 한다는 생각이 갑자기 들었기 때문에. 오케이 여기까지. ㅎ