Reputation: 1229
A first in my professional life, I must deliver a DLL to a customer that contains our base, generic software and an interface that makes it work the way the customer wants it + allows the customer to feed in inputs and read outputs.
Now my big problem here is, I may not show anything to my customer that he doesn't absolutely needs to know, because of intellectual property. This includes data types, which therefore I cannot even show him the signature of any of our internal methods. I have created data types and structures which mimic our own internal ones but which for example voluntarily omit unnecessary atrributes/elements or give them different names to hide hints to our private internal logic. And then the methods that get data map our own data structures and type into those. You get the picture.
Also, this time from a pure software architecture point of view, I do not want him to access certain members, attributes, variables ... because I do not need him to know that they exist or do not want him to modify them when he pleases and how he pleases. Yet they are solely related to that interface, and are not at all part of our internal software.
What I have right now is a class which serves as an interface, which he can instantiate. It basically provides get methods for output, methods to feed input and launch update calculations, and getters and setters for other parameters and values (like software versions or current state). Actual data variables for those parameters and other variables are hidden in my CPP file which gets compiled into the DLL, so they are not even declared as attributes of the class that we use as interface in the H file that I give to him, not even as private, and he doesn't know about them - he only has the getters and setters.
What design pattern should I be using here ? Could I actually put my variables in the H file that I share with my customer, as attributes of the class, as private ? But then, would he be able to change them from private to public, and by writting new methods for the class, accessing them and modifying them freely without the compiler complaining ? Could I otherwise contribute to my class and extend it in my CPP file or some other H file that he would not have access to ?
So many questions, as it is all new for me. But you get the general picture : I want to share the strict necessary, the utmost minimal information with my customer in this H file so he can make my DLL work and get his data outputs. And no more.
Thanks in advance, Charles
Upvotes: 2
Views: 639
Reputation: 5304
What design pattern should I be using here ?
Please refer to pimpl idiom for more details.
Could I actually put my variables in the H file that I share with my customer, as attributes of the class, as private ? But then, would he be able to change them from private to public, and by writting new methods for the class, accessing them and modifying them freely without the compiler complaining ?
Yes, he would. With pimpl it is still possible, but much more hard and requires reverse engineering.
Upvotes: 2
Reputation: 42924
First, you should consider building a DLL with a pure C interface, as having a C++ interface with STL classes at DLL boundaries is highly constraining (e.g. your client has to use the same Visual C++ compiler version and dynamically-link to the same CRT flavor you used to build the DLL).
At this point, you are free to develop a thin layer that will shield/hide your C++ implementation (compiled in the DLL and as such delivered as binary) to the customer.
You may also provide a simple public header file that could wrap the C interface layer exposed by the DLL in an nice C++ object-oriented way (kind of like ATL and WTL do for Win32 pure-C API functions).
Upvotes: 4