mercredi 5 janvier 2022

Should/Can we use names from dependency interface in our wrapping interface?

let us assume I'm making a wrapper of a third party library like f.e. OpenSSL, the wrapper allows to establish a TLS session, without making a direct dependency between client code and OpenSSL.

So basically, the library provides an abstraction for a OpenSSL TLS implementation (from client code point of view). To configure the OpenSSL, its interface offers a set o defines (f.e. pointing to cipher suits, tls versions etc.). The configuration is done by a client code, my library just needs to "forward it" to OpenSSL. So the question is how to construct the wrapping library interface in way where I still can keep its abstraction (do not use directly names from OpenSSL library ) and I'm not defining all required values again (or creating new values and mapping them to openSSL values)?

F.e. If OpenSSL has #define TLS_1_1 32, should my library make same define, keeping interface header file clean from any OpenSSL names ? #define MY_LIBRARY_TLS_1_1 32, or should I include openssl.h file and use openssl name: #define MY_LIBRARY_TLS_1_1 TLS_1_1 ?

The second option makes maintaining a bit simpler (in case OpenSSL values change, there is no need of modifications in my interface), but it creates a direct dependency from my interface to the OpenSSL interface and forces me to deliver OpenSSL header with my library ?

What is the right way to do this ?

Aucun commentaire:

Enregistrer un commentaire