问题
I've googled quite a bit, and found it weird that no one cared to explain why COM interfaces are immutable. I suppose that the reason you're unable to remove any methods from a COM interface, is because a client relying on that interface, would encounter an error, which isn't good. But why would adding new features to the interface change any of that? Has this something to do with the underlying vtable?
回答1:
If you add a method, a newer client that uses that method will fail when working with an older version of the component.
Older versions of the component won't have the new method unless you specifically add code to implement it, rebuild the component, and then reinstall the component on all machines that use the component.
If a newer version of the client attempts to call the new method on an older version of the component that doesn't have the method, undefined behavior will occur (likely a crash but silent data corruption is also possible). The new client will be attempting to call a method through a pointer entry in the vtable that did not exist when the old client was built so the old client will have some unrelated value in this location.
Of course, this wouldn't be an issue for you if you control both client and component and deploy them together but COM is designed for a much broader range of use cases than that.
回答2:
COM has a very strong DLL Hell problem. Several basic reasons:
- The programmers involved with writing the server and the client code rarely know each other, don't work together and have their own release schedules.
- Registering servers is by default machine-wide, affecting every single client program that depends on the server. Isolated COM with a reg-free manifest is a workaround.
- Early-bound COM (using a v-table) is very efficient but extremely intolerant to v-table changes. Mismatches are very hard to diagnose when the client code simply calls the completely wrong function or passes the wrong arguments. Late-bound calls through IDispatch is a workaround but slow.
- COM programmers are very strongly motivated to cheat, changing the interface {guids} causes pretty grumpy client programmers and awkward support calls. Making an interface backwards compatible is relatively easy to do, making it forward compatible never works. Only changing the interface guid is truly safe.
- Deployment of COM servers is often a client duty, they typically don't know enough about the server to troubleshoot and correct problems.
These are otherwise generic versioning problems, many runtime implementations suffer from them with various amounts of pain. A specific advantage in COM is that you can do something about it. Change the {guids} and a lot of the nastiness evaporates.
来源：https://stackoverflow.com/questions/29056322/why-is-the-com-interface-contract-immutable