이번 포스트를 시작하기 전에 먼저 말씀드리고 싶은 것은 제 글들은 정답을 말씀드리는 것은 아닙니다만 그래도 가장 좋은 답이라는 생각으로 정리하고 있습니다. 제가 글을 통해서 말하고 싶은 것은 소프트웨어를 설계하는 과정에서 많은 고민의 시간 끝에 내려진 결론과 그 결론을 도출하기 위한 충분히 타당한 근거입니다. 이러한 사고 방향을 바탕으로 여러분이 자신만의 설계에 가장 타당한 근거는 생각하고 그 근거를 바탕으로 설계 방향을 결정할 수 있기를 바랍니다.
컬렉션 객체를 디자인할 때 컬렉션의 내부 아이템을 순환(iteration)하기 위한 방법은 어떤 것이어야 할 까요? Iteration은 컬렉션 객체의 아이템을 순환하기 위한 아주 일반적인 방법입니다. 특히, Iteration은 컬렉션 객체의 타입에 관계없이 동일한 인터페이스를 적용할 수 있기 때문에 아주 매력적입니다.
답을 먼저 말씀드리면 Iteration은 사용하지 마세요. Iteration을 사용하면 왜 안되는지 하나씩 말씀드려보겠습니다.
Iteration은 컬렉션의 아이템 개수를 알 수가 없습니다
데이터 베이스 테이블과 같이 컬렉션의 모든 아이템을 구성할 수 없는 경우가 있습니다. 데이터 베이스의 테이블 질의 결과는 전체 레코드를 구성하기 보다는 전체 결과의 일부분씩만 사용하는 것이 처리 속도나 메모리 사용량 등에서 훨씬 효율적입니다. 따라서, 컬렉션 아이템의 시작은 알 수 있지만 그 끝을 알 수 없는 경우 iteration은 매우 효과적입니다.
메모리에서 구성하는 컬렉션 객체의 경우 기본적으로 메모리에서 구성할 수 있을 정도의 아이템 개수를 갖는다고 볼 수 있습니다. 즉 컬렉션의 시작과 끝이 명확합니다. 그 중 컬렉션 객체를 생성하는 시점에서 전체 아이템의 개수를 명확하게 결정할 수 있는 경우도 있습니다. 이런 경우는 배열과 같이 인덱스로 직접 아이템에 접근하는 것이 코드의 가독성이나 프로그램의 효율성 측면에서 매우 이득입니다. Linked-list는 컬렉션의 전체 아이템 개수를 위한 공간을 확보하는 것이 매우 부담이 되거나 컬렉션 중간에 아이템이 추가, 삭제되는 일이 빈번하다면 적합합니다. 검색 효율이 중요하다면 해시 테이블 같은 구조를 생각할 수도 있습니다. 그 외에 다양한 트리 구조 등 메모리에서 컬렉션 객체를 구성하는 자료 구조는 정말 다양합니다.
어떤 자료 구조를 사용하든 iteration에 대한 유혹을 뿌리치세요. Iteration 인터페이스는 iteration이 유효한지 여부를 나타내는 속성과 다음 아이템으로 진행하기 위한 함수로만 구성되어 있는데 두 가지 함수만으로 컬렉션의 아이템을 다루는 것은 너무 큰 제약 사항입니다.
의미적으로 linked-list는 iteration과 동일한 방법으로 아이템을 순환하게 됩니다만, 그렇다고 해서 linked-list 컬렉션의 인터페이스마저 iteration과 동일해야 할 필요는 없습니다.
Iteration은 다음 아이템으로 진행해야 할지 말아야 할지를 미리 알 수 없는 컬렉션 객체에 유리한 인터페이스입니다. 더 읽기 쉽고 이해하기 쉬운 인터페이스를 작성할 수 있는데도 iteration 인터페이스를 고집해야 할 이유는 없습니다.
Iteration은 컬렉션 객체의 구조에 독립적입니다
Iteration 인터페이스가 컬렉션 객체의 구조에 독립적이라는 의미를 잘 생각해보세요. 여러분의 소프트웨어에 컬렉션인 객체가 있습니다. 그리고, 그 객체를 사용하는 코드들이 존재합니다. 이 객체와 코드가 독립적일 필요성이 있습니까? 제 생각에는 이 둘이 독립적일 필요는 전혀 없습니다. 이 둘에 독립성을 부여하는 것은 오히려 코드를 이해하기 어렵도록 복잡하게 할 뿐이며 여러분의 데이터 모델에 자신이 없음을 의미하는 것입니다.
그럼에도 불구하고 컬렉션 객체와 컬렉션을 사용하는 코드가 독립적일 필요가 있는 경우가 있습니다. 가장 대표적인 경우가 데이터 베이스의 질의 결과 테이블입니다. 마찬가지로 어떤 외부 저장소의 데이터에 대한 결과 집합 역시 마찬가지입니다.
이러한 결과 레코드 집합을 저장하는 컬렉션 객체가 존재하며 그 컬렉션 객체를 사용하는 코드가 매우 강하게 연결되어 있다는 것은 질의가 바뀔 때마다 많은 클래스의 설계와 코드가 변경되어야 하는 것을 의미합니다. 결국 외부 저장소를 사용하는 것 자체가 많은 스트레스를 유발하게 됩니다.
결과 레코드를 처리하는 코드가 컬렉션 객체의 구조에 독립되어 있다면 소프트웨어의 코드는 다소 모호하게 되지만 그 만큼 유연해 짐을 의미합니다. 이러한 객체의 관계는 강한 연결로 인한 신뢰를 취하기보다 유연함을 얻는 쪽이 더 가치가 있습니다.
불필요한 디자인은 없습니다. 중요한 것은 그 디자인이 가지는 특징과 본질을 얼마나 잘 이해하고 사용하는가의 문제입니다. 만일 여러가지 디자인을 놓고 결정하기가 어렵다면 아무것도 모르는 개발자가 보더라도 이해할 수 있는 코드를 작성하는 것을 최우선으로 놓으면 됩니다.
Stratosphere631 