描述:
各位高手：
程序员对"友元"一般都不会陌生，但是我在用ATL编写COM程序时
遇到一个难题，就是不知如何使接口类的某些接口函数只能让部分
接口类访问，就是类似"友元"的关系。
解决方案1:
其实解决这个问题的难易全在于你对于"规范"、"通用"的偏执程度。
我也遇到过这个问题，我的第一反应是查一下COM里有没有现成的方案，没有，于是信心十足的想自已创造一个Pattern，可以成为类似问题的通用而又规范解决方案。于是我埋头设计，开始创造了"友元接口"这个概念，后来又想到用"认证调用"的方法，还设计过一种最复杂的回调接口机制。在设计的过程中，我把调用这个COM组件的客户假想成这个COM组件的"敌人"，"敌人"会用各种办法绕过你的"防御"，所以你要不断推翻自己的想法，强化你的"防御"。我越来越觉得客户是丑陋、无耻的，它会破坏一切正常秩序来调用它不该看到的方法。最后我精疲力尽了，我被自己折磨得快疯了。我不禁怀疑的问自己，"真的需要吗？"，"不需要吗？""需要吗？"，"不需要吗？"... ... 最后，我冷静的做了一次分析：这个COM，除了我的一位同事会调用外再也不会有人需要它了，它更不可能成为一个广为流行的COM，它只是在这套系统里扮演着一个普通的角色，并且谁也不能保证它能"活"多久，也许这套系统的下一个版本已经变成J2EE的了。客户端和COM都是用VC写的，源码也都在，没必要考虑其它语言调用。于是我确定了两个方案，一：在文档里写上"不要调用"；二：像上面提到的，另分出一个接口，不公布在类型库中，只提供一个头文件；第一种方案跟本不在用程序解决的范畴之内，第二种也是在语言的范畴内解决的，不设计跨语言的COM层次。
你猜我是怎么解决的？
我和正在专心写代码的同事说，这个接口的某某方法你不要调用，那是设计给其它人用的。他心不在焉地说"知道了"。事情就这样解决了，我连文档都没改。
我想说的是，规范固然重要，它也代表一个程序员的素质，但有时解决问题不要死钻牛角尖，要从实际出发、灵活处理、克服偏执的心理，做一个理智的程序员。
访问权限限定，1访问设定，是通过Dcomcnfg设置完成
2进程设定,通过编程修改Proxy/Sub来完成,你可以查一下代理/存根获取接口
信息的那个接口，好像是什么 Get Client Blanket进程级别的验证在com规范
中是通过修改这个
我觉得也没什么好的方法，照 LOP5712（LOP）说的去做，应该会避免一些问题，尽量去遵照COM的规范。
解决方案4: “友元”是对封装性的破坏。COM是封装得比较严格的。
不建议在C++中使用友元，更。。。。。。
在接口上做身份验证行不行？
解决方案6: C++的友员只是语言级上的保护，不过COM规范本身并没有提供这方面的功能，不过可以使用此法，将不止是语言级的保护
其实很简单，将你想让友员类访问的方法单独归成一个接口，这个接口的规格只有你的友员客户才知道，也就实现友员效果了