这些新的符号及其表示的复杂的间接类型是在我们对托管堆反复学习和认识之后产生的。面对生存期短暂的托管堆对象，我们需要某种精巧的方式来认识和使用它们，我们相信这些额外的间接类型可以给大家很多帮助。我们将在今后的专栏文章中详细讨论它们。
我们在此对一门 CLI 语言所选择的第二个设计层面表示了其对底层 CLI 实现模型的一层映射。选择什么样的映射取决于该编程语言定位于什么样的程序及程序员模型。当你选择一门 CLI 语言进行编程的时候，你实际上也是在选择遵从一种程序员模型。我们对于 C++/CLI 程序员的定位是那些历练较深的系统程序员，这些程序员通常所面对的任务是为高层的商业逻辑提供基础性的构造和关键性的应用，这时候她就必须要同时考虑系统的扩展性和性能，因此必须对底层 CLI 有一个系统级的视角。
学习 C++/CLI 的第三个要点是学习那些非 CLI 本身所直接提供的功能特性。这也是每一门面向 CLI 的语言所要面对的设计选择，也是各种 CLI 语言之间相互区分的一种体现。
例如， CLI 本身并不支持多类继承 (multiple class inheritance ，简称 MCI) ，而只支持多接口继承和单类继承。但 Eiffel 语言在设计其面向 CLI 的实现时就选择了支持源代码级的多类继承。这需要一种巧妙、甚至是复杂的设计将源代码级的多类继承映射为底层 CLI 的单类继承模型。 Eiffel 语言的设计人员认为这种映射对于 CLI 平台上的 Eiffel 程序员是一个利好的元素。
在此 C++/CLI 的第三个设计层面上，我们没有采用多类继承的方案。其中一个原因是我们不能说服自己多接口继承模型有任何不够简单或者优雅的地方。我们没有足够的经验来确定哪种方案绝对的优秀，但是我的直觉告诉我多类继承（ MCI ）是一个死胡同。我们在此设计层面上的主要关注点在于为那些 CLI 本身所欠缺的地方提供一些额外的解决方案，我们主要集中在以下三个方面：
1． 为某些 CLI 要求手动干预的地方提供一种自动化的解决方案，例如确定性终止化操作（ deterministic finalization ）和稀有资源释放。
2． 提供一些特殊的类成员函数——例如拷贝构造器和拷贝赋值操作符，以及在 CLI 直接支持的操作符的基础上再为一些操作符提供一些扩展支持——例如用来支持函数对象（ function object ）设计模式的调用操作符“（）”。
3． 提供一种静态的参数化机制来支持设计适用于 CLI 类型的标准模板库（ STL ），这是因为 CLI 中的泛型机制在我们来看对于当代的参数化设计是不够的——虽然我们也支持它们。
以上几点在我们的系列专栏中都将有相关的讨论。特别地，我们将会详细阐释 C++/CLI 中的模板和泛型机制。
| 
