Using Provider Pattern - Multiple Abstract Classes

Question

Created a group of related providers using the provider pattern. Now would like to enhance my providers due to new requirements given to me. The providers were created for a bunch of customers who integrate with our web services. Now some of the same customers would like to integrate with us using a web page. Going thru our web page the front end logic of course would be different but half of the provider logic would be the same. So I was thinking of adding another abstract class in particular customers provider to handle web page integration with provider. Here's a code ex using possible enhancement:

//Same Customer provider dll      
//Methods defined for handling web service integration
public abstract class XMLBaseProvider : ProviderBase


//Methods defined for handling web page integration logic
public abstract class XMLWebPageBaseProvider : XMLBaseProvider

Now in the app.config I define another provider section that points to XMLWebPageBaseProvider along with a new provider name. This works but an wondering am I abusing the provider pattern coding it this way? Is there any concerns or gotchas I should be worried about by doing this. Has anybody here implemented this provider pattern like I described above?

Also note we probably will get more customers who will integrate with us using the web page integration. I would just hate having to keep adding more and more providers(dlls) to solution.

Thanks, DND

Multiple abstract classes isn't necessarily a bad idea, but something to consider might be the composition over inheritance paradigm. http://en.wikipedia.org/wiki/Composition_over_inheritance — Jeff, Sep 16 '11 at 18:39
What if you will need a non-XML web page provider in the future, like JSON? In this case some xml-specific properties and methods that are declared in XMLBaseProvider become redundant. I would do like this: WebPageBaseProvider as an abstract subclass of ProviderBase and then XmlWebPageBaseProvider as a subclass WebPageBaseProvider. — mishau, Sep 16 '11 at 20:23

score 1 · Accepted Answer · edited May 23 '17 at 12:20

I think your ideas are good. For what you described, your design will work fine. As one of the commentators noted, though, the requirements might expand into JSON. In my experience, the need for different formats always grows over time. When that happens, inheritance becomes quite brittle. The class hierarchy will grow to more and more levels of abstract classes. In the end, it will be difficult to manage.

The commentator suggested using composition and I agree. A strategy or visitor pattern will likely serve you better over the long run.

If the application is critical to the business and the business is growing, consider going a step further. Move as much of the provider logic as possible out of the code and into a configuration file or configuration database. This will be a big win in the long run because it minimizes the amount of code that must be change when the requirements grow. Changing the code risk creating bugs, mandates a new build and deployment, etc. Changing some data is much easier and less risky.

This strategy is generally referred to as data-driven programming. Have a look at this question.

I can see possibilities of using the strategy pattern inside my base provider. Really got excited when realizing that this pattern will allow me to adapt to change with the provider. Thanks — DotNetDude, Jan 11 '12 at 21:12

Using Provider Pattern - Multiple Abstract Classes

1 Answers1