请问《COM技术内幕》书中的有关问题
请教《COM技术内幕》书中的问题
通过别人的推荐我在网上下载了《COM技术内幕》的PDF——Dale Rogerson著，杨秀章译——用来阅读和学习，因为对设计模式不了解又是第一次接触到COM，刚开始就被这种程序的设计方法震撼到了，这两天看到第8章组件的聚合，在第164页时，发现了一个非常困扰的问题：
作者在前面的篇幅里企图表达这么一个意思，外部组件聚合了内部组件的一个接口IY,被聚合的内部组件的QueryInterface实现是通过存储着外部组件的IUnknown类型的指针成员变量pIUnknownouter，来调用外部组件的QueryInterface实现的。而外部组件在这个函数中，对IY接口的查询居然通过自己存储的IY接口的指针m_pIY来访问QueryInterface函数,我想这不是很明显的死循环吗，虽然他加了一个预编译条件说，也可以直接返回m_pIY。可是对m_pIY指针的赋值在这一章中始终没有讲到，后面列的程序清单里也没有看到。但是他意犹未尽的在一段描述文字里面说——（被类厂调用的外部组件CA::ini()函数中将通过CreateInstance初始化内部组件对象CB）“在继承前面的处理之前，最好先检测一下内部组件是否真的实现了IY接口”，我知道他的本来意思不是想检测内部组件有没有实现了IY接口，虽然他这么说。程序一定是在这里初始化m_pIY,因为对应的非代理IUnknown的NondelegatingQueryInterface函数就实现了对IY接口的查询，可是居然还是调用内部的代理IUnknown接口的QueryInterface函数。还没看到后面但已经在这个地方卡住了，想请问曾经读过这本书各位大侠，这里到底是不是出现了死循环，还是什么问题？
------解决方案--------------------
你理解是错误的把
IX是外部接口，耦合了一个IY接口，对IY调用QueryInterface，或转到IX的QueryInterface，而对IX调用QueryInterface，不会转到IY，怎么会循环？重点就是任何QueryInterface都最终到最外层的接口的QueryInterface
------解决方案--------------------
呵呵，好帖啊IX是外部接口，耦合了一个IY接口，对IY调用QueryInterface，或转到IX的QueryInterface，而对IX调用QueryInterface，不会转到IY，怎么会循环？重点就是任何QueryInterface都最终到最外层的接口的QueryInterface
------解决方案--------------------
转到IX的QueryInterface最终也会返回IY的指针的，因为IX保存了IY的指针
转到IX的最重要目的在于：
1。如果IX耦合了除了IY之外的接口，即使你通过IY查询，只要你转到IX，最终也能发现
2，任何一个接口，无论你从IX还是IY查询，最终得到的指针都是一致的
注意：这里重定向的是对QueryInterface的调用，而不是最终返回的结果。如果你查询IY的接口，最终当然得到IY的指针，只是这个指针是通过IX的QueryInterface返回的
------解决方案--------------------
个人认为你水平未到，明明很清楚的事情，你竟然完全不明白:)这是经典书籍，不要因为自己读不懂就觉得是别人责任。
------解决方案--------------------
这个在IX设计之初就考虑好了，根本不需要“改”掉。
------解决方案--------------------
M$好像对COM技术的支持越来越弱了。
------解决方案--------------------
确实，COM/DCOM/COM+
都属于过时的技术了，但是其基本思想在现代的web service及其他面向对象的技术中都是一样的。
------解决方案--------------------
Web Service
------解决方案--------------------
corba/j2ee/(com(ole2))3中主流构件实现规范，com应该是演进成.net了
------解决方案--------------------
164页对应实体书的多少页？我正好有这本书，可以看一看。
通过别人的推荐我在网上下载了《COM技术内幕》的PDF——Dale Rogerson著，杨秀章译——用来阅读和学习，因为对设计模式不了解又是第一次接触到COM，刚开始就被这种程序的设计方法震撼到了，这两天看到第8章组件的聚合，在第164页时，发现了一个非常困扰的问题：
作者在前面的篇幅里企图表达这么一个意思，外部组件聚合了内部组件的一个接口IY,被聚合的内部组件的QueryInterface实现是通过存储着外部组件的IUnknown类型的指针成员变量pIUnknownouter，来调用外部组件的QueryInterface实现的。而外部组件在这个函数中，对IY接口的查询居然通过自己存储的IY接口的指针m_pIY来访问QueryInterface函数,我想这不是很明显的死循环吗，虽然他加了一个预编译条件说，也可以直接返回m_pIY。可是对m_pIY指针的赋值在这一章中始终没有讲到，后面列的程序清单里也没有看到。但是他意犹未尽的在一段描述文字里面说——（被类厂调用的外部组件CA::ini()函数中将通过CreateInstance初始化内部组件对象CB）“在继承前面的处理之前，最好先检测一下内部组件是否真的实现了IY接口”，我知道他的本来意思不是想检测内部组件有没有实现了IY接口，虽然他这么说。程序一定是在这里初始化m_pIY,因为对应的非代理IUnknown的NondelegatingQueryInterface函数就实现了对IY接口的查询，可是居然还是调用内部的代理IUnknown接口的QueryInterface函数。还没看到后面但已经在这个地方卡住了，想请问曾经读过这本书各位大侠，这里到底是不是出现了死循环，还是什么问题？
------解决方案--------------------
你理解是错误的把
IX是外部接口，耦合了一个IY接口，对IY调用QueryInterface，或转到IX的QueryInterface，而对IX调用QueryInterface，不会转到IY，怎么会循环？重点就是任何QueryInterface都最终到最外层的接口的QueryInterface
------解决方案--------------------
呵呵，好帖啊IX是外部接口，耦合了一个IY接口，对IY调用QueryInterface，或转到IX的QueryInterface，而对IX调用QueryInterface，不会转到IY，怎么会循环？重点就是任何QueryInterface都最终到最外层的接口的QueryInterface
------解决方案--------------------
转到IX的QueryInterface最终也会返回IY的指针的，因为IX保存了IY的指针
转到IX的最重要目的在于：
1。如果IX耦合了除了IY之外的接口，即使你通过IY查询，只要你转到IX，最终也能发现
2，任何一个接口，无论你从IX还是IY查询，最终得到的指针都是一致的
注意：这里重定向的是对QueryInterface的调用，而不是最终返回的结果。如果你查询IY的接口，最终当然得到IY的指针，只是这个指针是通过IX的QueryInterface返回的
------解决方案--------------------
个人认为你水平未到，明明很清楚的事情，你竟然完全不明白:)这是经典书籍，不要因为自己读不懂就觉得是别人责任。
------解决方案--------------------
这个在IX设计之初就考虑好了，根本不需要“改”掉。
------解决方案--------------------
M$好像对COM技术的支持越来越弱了。
------解决方案--------------------
确实，COM/DCOM/COM+
都属于过时的技术了，但是其基本思想在现代的web service及其他面向对象的技术中都是一样的。
------解决方案--------------------
Web Service
------解决方案--------------------
corba/j2ee/(com(ole2))3中主流构件实现规范，com应该是演进成.net了
------解决方案--------------------
164页对应实体书的多少页？我正好有这本书，可以看一看。