Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a class, called PolicyProvider, at present with the following (abridged) interface:

public interface IPolicyProvider
    List<Policy> GetRenewalPolicies(Client client, int financialYear);

The purpose is quite obvious - every year, the insurance renews for the client, and they will get a number of new policies.

The thing is, the policies change year by year. Therefore, a concrete implementation of the class needs to be changed every year (or amended with lots of ugly little "if's" evaluating the financial year). I can see that over time this will become horrendous.

In this case, what design pattern is most appropriate?

share|improve this question
I don't really think you should ask for "design pattern". You should ask for OO design and use design pattern only if it emerges from this design or if you are 100% sure this is good fit for that pattern. – Euphoric May 9 '13 at 6:55
Most likely a factory pattern, with your core PolicyFactory creating policies for any given client. I recommend starting with a PolicyFactoryFactory class, a factory of factories, that is, capable of creating a PolicyFactory for particular year (be it PolicyFactory2012 or PolicyFactory2013 etc.). :) – Konrad Morawski May 9 '13 at 7:06
You can try to decompose the code into a number of "code blocks", and then see if next year's policy can be composed from these blocks. However, if next year's policy turns out to be unforeseeable (requiring completely new code blocks and behavior), code change is inevitable. – rwong May 9 '13 at 7:10
I would use some kind of config file... editing code every year is a PITA. Adding a line in a txt file or whatever is easy as pie. Or you could store data in a db and let clients put the data in it through an interface. – Florian Margaine May 9 '13 at 9:53
+1 @Florian. You probably shouldn't have to change your code to change the policies. – KChaloux May 9 '13 at 12:47
up vote 3 down vote accepted

Following nulliusinverba's suggestion, I'm creating an answer out of my original comment.

I see it as a scenario for a factory pattern, with your core PolicyFactory (or provider) creating policies for any given client.

You could then in turn have a PolicyFactoryFactory class, a factory of factories, that is (nevermind the awkward naming), capable of creating a PolicyFactory for particular year (be it PolicyFactory2012 or PolicyFactory2013 etc.).

Obviously, this metafactory could still be able to parse external files and build policies out of their contents (as Florian suggested).

share|improve this answer

A standard approach to avoiding "if"s is to use subtyping and dynamic binding. All you need to do is to create subtype policies for each financial year.

share|improve this answer
+1. I would add with a factory whose sole purpose is to instantiate the appropriate policy for that particular year. – Neil May 9 '13 at 10:55

You should use the Domain Model Pattern because "policies" (especially as you've described them) are subject to frequent change and you need to keep them sufficiently isolated so that you will not confuse or disrupt the "normal" path of execution.

Reasons to Use the Domain Model

In those cases where the behavior of the business is subject to a lot of change, having a domain model will decrease the total cost of those changes. Having all the behavior of the business that is likely to change encapsulated in a single part of our software decreases the amount of time we need to perform a change because it will all be performed in one place. By isolating that code as much as possible, we decrease the likelihood of changes in other places causing it to break, thus decreasing the time it takes to stabilize the system.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.