Reputation: 16121
In the class diagram below you can see my current approach of the plugin/extension system. I want to offer the extensions an API for general/global things. But the exposed API should comprise just a subset of the actual functions of the referenced object. My first thought was to use an interface. The problem with that is that an evil plugin could downcast the interface to the internal class and mess things up. (Should I even care?) The second thought was to use the proxy pattern. Currently I use both of them. Which is not really necessary, I guess. But having binary compatbility in mind how can I reduce complexity here?
Upvotes: 0
Views: 296
Reputation: 98505
Should I even care?
No. C++'s features are there to help you write correct software, not to protect you from malicious developers. It's not the language's job to do that. Your APIs should be designed for correctness, comprehensiveness and ease of use.
having binary compatbility in mind how can I reduce complexity here?
Create API classes that don't inherit from anything. Look at the Leap Motion C++ API for inspiration how to do it correctly.
Upvotes: 1
Reputation: 11011
If you want plugins that can not somehow corrupt your program then you have to make those plugins as separate processes. Then plugins are running in separate memory space and communicate with your application over pipe or socket.
Upvotes: 2