Design and Implement the Public Interface (API) for Your Feature

[thiruvasagamani]

Design and Implement the Public Interface (API) for Your Feature

In the example solution, we want to retrieve and manage pricing information by connecting potentially to several different back-end systems in our organization. One way to accomplish this is to identify the common business functionality proffered in each system, and craft a common API. Of course, this means we could be sacrificing some functionality that is available in our more advanced pricing systems, simply because there is no analog for it present in other older or less-capable systems. Fortunately, there are some strategies for using this pattern even when some back-end providers don't match up well to others. These include:

    * Providing public properties in your abstract provider interface, and in your API, that allow client applications to query the availability of features in the currently configured provider. A good example of this is in the EnablePasswordReset and RequiresQuestionAndAnswer properties of the Membership API. Both are read-only properties that return a Boolean value indicating whether the currently configured default provider allows or has the ability to service password reset and question and answer challenges.
    * Using "glue" code in your provider implementation to close the gaps between the more advanced providers in your organization and the less capable ones. Essentially, you would implement functionality that the back-end system is missing within your provider.

For our example, the public API that we have designed is simple, and focuses on exhibiting common qualities of the provider pattern. Our focal point is the abstract Pricing class, and we have one peripheral class named PriceQuote. All of the classes that participate in forming our API should have implementations that can vary independently of the back-end providers that might receive messages from them. Our abstract focal point class should have some static read-only properties to retrieve values for common configuration parameters of the currently configured provider, and static methods and events that define and expose the service actions offered. It should also have Provider and Providers properties that return the default configured provider and all configured providers, respectively. Peripheral classes will need a ProviderName property that directly links back to the name of the provider that is responsible for creating them. This is necessary because these objects may contain methods that call the corresponding methods on the provider class identified by ProviderName.

Source : MSDN