Method to Natively Support Multiple APIs with Different Character Encoding by a Singular Implementation (03-Nov-2009)
With the move of many applications to Unicode support they often switch from strings based on byte characters to strings based on wide character types as used in UTF-16 or UTF-32 string representations. This change is often reflected in the programming API of that application as well. This article explains how to support old and new versions of the interface at the same time in an efficient way.
Method to Natively Support Multiple APIs with Different Character Encoding by a Singular Implementation
Disclosed is a method to support multiple versions of an API that have the same basic structure but differ in a detail like one version handling byte character strings while another version handles wide character strings. In a component implementing one of those APIs the implementation has to be adapted to support the new interface and if different versions of the application are to be supported you actually have to deal with both versions of the interface.
An obvious solution to this problem would be to create multiple independent implementations. This approach causes a lot of additional work and imposes the risk of accidental diversification of both variants.
Another solution would be to create one implementation and additional wrapper implementations as described in the Adapter pattern in [*] that convert the data structure dynamically from their current representation to the representation used in the implementation. While this solution is appropriate in a situation where the implementation has to deal with multiple external software components at the same time with the same data processed it is wasting system resources (and thus slowing down data processing) by converting the alien data format to the internal format for processing although it is clear that the end result has to be converted back to exactly the same alien data format afterwards.
A specialized implementation using the alien data format for internal processing as well is performing better here. Some programming languages (like C++ for instance) support template implementations that can be instantiated to the various required data types, thus providing a method to automatically create two implementations from one source. This article describes a method to achieve a similar goal in an environment without a template mechanism (like with the programming language C). In such a situation a method to create multiple variants from one singular implementation is useful to safe a lot of duplicated work and to guarantee consistency between the various versions.
While this method can be applied to various data types that get modified this article will emphasize on string representations. Assume that an implementation has the requirement to support an API with different string types in different versions, for instance older versions of an application that was using legacy strings based on single byte characters and newer versions of the same application, providing basically the same interface but with the modification of having all strings represented as UTF-16 strings. This method divides the component code into four categories: First there is all code that is not affected by the interface variants and thus can be shared in the resulting binary code. Second there is code that follows the same basic implementation but cannot share t...
Find More Documents Like This
Download this Disclosure
Click here if you want to sign-in now.
