C++에서는 Template라는 형태로 Generics를 제공해 왔습니다. 패턴적인 측면에서는 C#의 Generics와
크게 다르지 않으나, 결정적인 차이가 있다면 C#에서는 CLR이 지원한다는 것입니다. 일종의 매크로(템플릿에 제공된 각 형식
매개 변수에 대한 특수화된 형식을 생성)일 뿐인 C++의 Template과는 달리 Generics는 Runtime시에 JIT
컴파일러에 의해 적절히 해석되고 Native Code로 컴파일된다는 것입니다.
C++와 같은 후기 바인딩 방식에서는 단지 클래스 또는 인터페이스의 상속을 통한 바인딩이었기에 Logic의 확장이
어려웠고, 형식의 안정성에서의 문제점도 꼼꼼히 따져야만 했습니다. 적어도 전달되는 클래스는 같은 클래스에서 상속을 받거나 같은
인터페이스를 구현해야 했습니다. 물론, COM의 IUnknown 같이 자기기술자[Self-Descriptor]를 가진
클래스/인터페이스를 만들면 해결할 수 있겠지만 그 노력은 만만치 않습니다. C#의 Generics를 적용하면 'Logic'과
'Logic에 의해 다뤄지는 객체'를 명확하게 구분할 수 있습니다.
결국 Domain/Business Logic을 구현이라는 점에서는 크게 다를 바가 없지만 그 유연성에 있어서는 상당히 선택의 폭이 넓어졌다고 할 수 있습니다.
-- JAVA의 Generics (Parametric polymorphism) --
Java의 Generics는 Pizza라는 프로젝트로부터 시작되었으며, 이후 GJ라고 이름이 붙여졌고, JSR로 바뀐
것입니다. Sun사는 Java Virtual Machine을 수정할 필요가 없는 구현을 선택했습니다. 따라서 Sun사는 수정되지
않은 가상 시스템에서 Generics를 구현함으로 해서 많은 단점들을 가지게 되었습니다.
Java Generics는 어떤 실행 능률도 높여 주지 못합니다. Java Compiler는
List<Integer>라는 Parameterized Type을 만들면 Integer를 Object로 모두 변환하고
필요한 곳에 (Integer)형 변환을 실행합니다. 이는 수정되지 않은 Java Virtual Machine이 값
형식(Value Type)에 대해 Generics를 지원하지 못하기 때문입니다. 따라서 Java의 Generics에서는 실행
효율성을 얻을 수 없습니다.
Java의 Generics는 erasure of the type parameter(매개변수 타입의 말소)라는 것에
의존하기 때문에 Runtime시에 List<Integer>는 List라는 클래스와 동일한 클래스로 표현됩니다. 이것은
어떤 클래스가 List<Integer>인지 List<String>인지 Runtime시에는 알 수 없다는
것입니다. 이는 Runtime시에 Generics 형식의 Instance에 대한 형식 매개 변수를 확인할 수 있는 방법이 없으며
다른 리플렉션(Reflection) 사용이 엄격하게 제한된다는 의미입니다.
출처 : vs 2005로 배우는 C# 게임 프로그래밍
델파이2009에도 Generics가 추가 되었군요.
Template의 영향력이 크네요.
STL과 같은 구조의 라이브러리가 전언어에서 구현가능하겠군요.
STL은 Standard Template Library약자로
98년에 C++표준이 되어 C++컴파일러에는 모두 포함되어 있다.
