Java 객체 생성 순서 문제
Saturday, April 5th, 2008문제 제기
프로그래밍에서 고전적으로 발생하는 문제점 중 하는 서비스가 인스턴스화 될 때, 부가적인 다른 서비스들을 필요로 한다면, 서비스의 생성 순서에는 의존트리가 발생하게 되어, 생성규칙이 까다로워 지거나, 단순히 생성 순서를 변경하는 것 만으로도 Null 익셉션을 발생시켜버리게 된다는 점이다. (여기서 서비스라는 것은 기능 제공 집합을 의미하고자 씌여졌으며 일반적으로 객체라고 생각해도 무방하다)
결국 서비스 생성을 감독하는 모듈은 정확한 모든 사전지식을 이해한 사람이 작성해야만 하는 제약이 생기게 된다. 자체 솔루션이나 개인 프로젝트라면 이것은 크게 문제가 되지 않을지도 모르지만, 이클립스등과 같은 불특정 다수가 참여하는 약설계 협력 시스템에서는 그것이 사실상 불가능하다.
예를 들어, 노트 패드가 있다고 가정하자. 이때, 사용자가 내용을 변경시킬 때 마다 UndoManager가 문서를 추적하고 UndoHistory를 만들 것이다. 이 서비스를 UndoService라고 하자. UndoService는 노트패드의 TextArea를 Listen해야 하므로 반드시 TextArea가 먼저 만들어 져야지만, UndoService가 시작될 수 있을 것이다. 이 제약은 별 것이 아닌 것 같지만, 거시적인 프로그래밍에 제약을 주게 되므로 가장 Clear해야할 감독 모듈의 가독성과 변화 적응성을 떨어뜨려 버리고 만다.
또 SelectAll 이라는 Action은 노트패드의 전체 내용을 선택상태로 만들어주는 액션이라고 할 때, 이 액션이 제대로 수행되기 위해서는 TextArea에 대한 참조를 가지고 있어야 한다. 하지만 UI가 생성되는 시점에서 SelctAll 액션은 메뉴 또는 버튼으로 기여하게 될텐데, 이 시점에 TextArea가 이미 구성이 되었는지 그렇지 않은지를 명확하게 판단하기란 어렵다. JFace냐 Swing Application Framework를 이용했느냐에 따라 구성 순서는 달라지게 되고, 이 모든 스펙을 이해하고 코드를 디자인 하는 것은 낭비적인 돌파 방법이다. 프레임 워크를 직접 개발하는 것 역시 매우 낭비적인 일이다. (이미 존재하는 훌륭한 프레임워크들은 다 존재하는 이유가 있다.) 어차피 그렇게 한다 하더라도, 소스를 변경하고 버전업함으로써 발생하는 복잡성과 결과 비예측성은 쉽게 통제할 수 없게 되어버린다.
해결 방법
자원이 준비되었을때 특정한 작업을 수행하도록 작업을 예약하도록 만든다.
Platform.scheduleTaskOnService(String serviceId, Task task);
Platform.registService(String serviceId, Object serviceObject);
이때 Platform은 특정 서비스가 등록되면 거기에 예약된 작업들을 찾아내어 서비스의 인스턴스를 참조 시켜 실행되도록 하는 책임을 진다.
위와 같은 방법을 이용하면 특정 서비스가 준비되면 어떠한 작업(task)을 수행하라와 같은 명령을 줌으로써, 코드의 처리순서를 플랫폼이 자동적으로 처리하게 만들 수 있다. 이제 SelectAll 액션은 손쉽게 그냥 생성된 후에, 만약 플랫폼에 TextArea라는 서비스가 준비되면 자동적으로 TextArea를 참조하게 될 것이다. 이러면 순수히 구현의 문제 때문에 발생하는 객체 생성 순서의 제약을 벗을수 있게 되고, 좀더 유연하고 설계 개념에 근접한 안전한 코딩을 할 수 있다.
