C++等语言的“面向对象”是源代码级别的，是由编译器为你呈现的“一片‘面向对象’的假象” ，它只限于编译器的这一头（输入），编译器的另一头（输出）同样是一堆十分“physical”的二进制指令序列，和C等面向过程的语言的编译输出没有本质区别。所以NewB程序员说，“我能用C写出和C++同样编译结果的东东来”，NewC程序员也说，“我的代码可以通过C++的类封装检查，但执行结果完全可以破坏对象封装，管你是不是私有成员。。。”
COM规范的“面向对象”是二进制级别的，接口形式的封装界面，很好地隔离了对象的内部知识，交互完全基于对既定契约的查询。这些优点同时也为它自己埋下了“祸根”，事实证明，COM组件的封装太过Physical，而且它所用的用于自我描述的机理（typelib）却不能完备地描述自己，这种描述于人于己都是那么无力苍白，使COM无法摆脱接口泛滥、Dll地狱等等早就存在的困扰。。。
那么怎么办，技术要进步！某位大师说过，“所有的软件问题都可以通过引入一个中间层来解决。” 微软的精英们在二进制系统的上面又为我们建造了一个“上层建筑”的平台（CLR），把软件组件封装从“物理空间”架到了“逻辑空间”，基于metadata的类型描述形式和基于IL的指令描述，对象只有通过CLR的ClassLoader才能按需进入二进制指令序列的“物理世界”。由此可见，.Net Framework 的CLR提供的Assembly是一种更高层次的对象模型，它是属于逻辑空间的并且是本地完善描述的。
绝妙的设计，没有问题了吗？呵呵，问题会有的，不然技术怎么进步？