템플릿의 장점과 문제점
처리해야 하는 타입은 다르지만, 각각의 타입에 대해서 처리해야하는 작업이 동일한 코드를 작성해야하는 경우 템플릿은 분명 큰 도움을 제공하는 도구이다. 하지만, 템플릿으로 확장된 타입(클래스)들은 완전히 독립된 타입으로써 존재하기 때문에 클래스 간의 상속과 관계가 정의되지 않고 느슨해진다. 즉 각각의 클래스가 특정 타입으로 고정되는 경향이 발생한다.
템플릿으로 중복 코드를 압축할 수 있는 효과는 있지만, 거꾸로 템플릿을 사용하는 입장에서는 템플릿으로 확장된 타입에 의존해야 하는 문제 때문에 유사한 코드가 반복될 수 있는 문제가 발생한다.
템플릿으로 인해 야기된 코드의 반복 문제를 해결하기 위해서는 템플릿에 의존하는 코드 역시 템플릿으로 작성되어야 하는데, 모든 코드를 처음부터 끝까지 템플릿에 의존해서 작성하는 것은 현실적이지 않다.
템플릿의 타입 정의
템플릿은 하나의 개별 타입을 정의하기보다는 템플릿의 코드 압축 효과를 고려해서 구현을 확장하는 용도로 사용하는 것이 좋다. 타입을 정의하거나 프레임웍 같이 프로그램의 추상화 영역에 템플릿을 사용하기 보다는 소비자가 존재하지 않는 구현 코드와 같이 구체화된 코드 영역에서 사용하는 것이 바람직하다.
템플릿의 인스턴스화에 의해서 추상적인 코드가 실제로 존재하는 코드로 만든다는 사실을 생각해보면, 타입을 정의하기 위해 템플릿을 사용하는 것이 바람직하지 않음을 알 수 있다.
템플릿에 의존하지 않은 타입 정의
추상 데이터 타입을 정의하는 경우 반복된 코드를 발견하는 경우가 종종있다. 특히, 컨테이너 역할을 하는 코드의 경우 단지 처리해야 하는 요소의 타입만 다를뿐 동작 방식은 크게 다르지 않기 때문이다. 템플릿을 사용하지 않는다면, 코드의 반복은 피할 수 없기 때문에 템플릿에 의존해 추상 데이터 타입을 정의하지만 이는 앞서 언급했듯이 완전히 독립된 타입들이 정의되는 문제를 낳게된다. 다소 불편함이 따르더라도 템플릿을 구체화한 타입을 정의하기 보다는, 클래스로 타입을 정의하고 구현을 템플릿에 의존하는 것이 바람직하다.
템플릿이 사용된 프로그램 API
프로그램 API를 템플릿으로 디자인하면 실제 코드의 생성은 API를 사용하는 모듈에서 이루어지기 때문에, 라이브러리와 프로그램을 동시에 개발하는 경우 헤더 파일의 관리에 주의를 기울여야 한다. 템플릿으로 작성한 헤더 파일을 수정 과정 중에 작업 내용을 잃어버리는 경우가 종종 발생하기 때문이다.
STL와 같이 충분히 완성된 템플릿 라이브러리를 제외하고 템플릿 클래스들은 프로그램 API나 타입 정의등 인터페이스의 용도로 사용하는 계층에서는 나타나지 않는 것이 좋다. 템플릿 클래스들은 더이상 노출되기 힘든 코드의 내부에서만 사용하도록 감추는 것이 좋다.
Stratosphere631 