C# Inheritance – How to Handle Custom Logic for Multiple Customers

business-logiccinheritance

We got a project where we have to process certain requests which the customer sends. The request is either in a generic format or in a customer format (all xml) which is then converted to the generic version.

Then some objects are created which are stored in the clients database to be read at a later moment.

Then the moment comes we have to read this information and do stuff with it. 100% of this will be done in a generic handler class, but each customer will have parts that it would like to have differently handled.
This can be about any of the fields we process.

Me and my colleague were arguing about the best way to implement this without getting 100+ classes that inherit from the generic version and override those methods that process a certain field the customer wants different. Soon the discussion drifted off to the use of reflection (we program in C#) and dirty configuration files.

I tried searching Google and this site, but couldn't find anything closely related, perhaps I don't know the terms to search for. I already tried these links, but do not cover my case or are actually about something else.

A bit more information about the process:
The custom parts involve certain codes that only that customer uses or certain business rules that only apply to one customer. On top of that it is possible that certain cases should be completely ignored for one or two customers where the base class does not.

The question is:
What is the best way to handle customer specific logic within a generic process?

If this is a duplicate, I'd really like to know how you found it!
If there is more information needed, I'd be happy to supply.

Update:
I created this picture in the hope it would give a better understanding of what I want to achieve. As you can see in the picture, each customer has its own set of overrides of the bigger process.
Customer specific logic

Best Answer

There are several options you can consider to tackle this problem at the design level.

Pattern-wise, you might want to get yourself a refresher about, including, albeit not limited to:

The abstract factory design pattern

http://www.dofactory.com/net/abstract-factory-design-pattern

which could maybe used in combination with:

The strategy design pattern

http://www.dofactory.com/net/strategy-design-pattern

If statefulness of your implementation is likely to come into play, the state design pattern, in combination with either or both the above, may also help (also presented dofactory).

'Hope this helps,

Related Topic