QCA
- Note
- You don't need to understand any of this to use QCA - it is documented for those who are curious, and for anyone planning to extend or modify QCA.
The design of QCA is based on the Bridge design pattern. The intent of the Bridge pattern is to "Decouple an abstraction from its implementation so that the two can vary independently." [Gamma et.al, pg 151].
To understand how this decoupling works in the case of QCA, is is easiest to look at an example - a cryptographic Hash. The API is pretty simple (although I've left out some parts that aren't required for this example):
The implementation for the Hash class is almost as simple:
The reason why it looks so simple is that the various methods in Hash just call out to equivalent routines in the context() object. The context comes from a call (getContext()) that is made as part of the Algorithm constructor. That getContext() call causes QCA to work through the list of providers (generally plugins) that it knows about, looking for a provider that can produce the right kind of context (in this case, a HashContext).
The code for a HashContext doesn't need to be linked into QCA - it can be varied in its implementation, including being changed at run-time. The application doesn't need to know how HashContext is implemented, because it just has to deal with the Hash class interface. In fact, HashContext may not be implemented, so the application should check (using QCA::isSupported()) before trying to use features that are implemented with plugins.
The code for one implementation (in this case, calling OpenSSL) is shown below.
This approach (using an Adapter pattern) is very common in QCA backends, because the plugins are often based on existing libraries.
In addition to the various Context objects, each provider also has a parameterised Factory class that has a createContext() method, as shown below:
The resulting effect is that QCA can ask the provider to provide an appropriate Context object without worrying about how it is implemented.
For features that are implemented with variable algorithms (for example, HashContext can support a wide range of algorithms - MD5, SHA0, and SHA1 in the example above; and CipherContext and MACContext can also do this), we need to be able to let applications determine which algorithms are supported. This is handled through the InfoContext class. A typical example is shown below:
Note that InfoContext is itself a feature, so you have to add it to the createContext() method for the provider, as shown below:
Documentation copyright © 1996-2024 The KDE developers.
Generated on Sat Dec 21 2024 17:03:55 by doxygen 1.12.0 written by Dimitri van Heesch, © 1997-2006
KDE's Doxygen guidelines are available online.