Using design patterns to model a subscription system - oop

Question

Here briefly are the business requirements.
I have an entity called PricingSchedule that represents a "subscription" to a system. We use the term "Pricing Schedule", not "subscription" in our team's ubiquitous language, but in theory, a subscription is the same thing.
What determines the Price of the PricingSchedule is the combination of two things:
1. the "duration" of the PricingSchedule (aka, how long is your subscription... 1 year, 2 years, etc...
2. how many Styles (another entity) you want to include in your PricingSchedule. You have two options for how to include Styles; 1. pay per Style, 2. pay for all Styles
Number two is a newly added requirement. Before, it was primarily the PricingSchedule's Duration that determined the Price.
My problem is this... the Price of a PricingSchedule doesn't mean anything when either the Duration, or StylePricingType is applied by itself. I can only get the final Price when they're combined together; aka, 2 years duration with 5 styles.
We have four possible pre-determined durations, ranging from a couple of days, to a 3 or 4 years.
We have two possible ways to bill Style selection; 1. per Style or 2. all Styles. These two things combined then determined the overall Price.
I started thinking the Strategy design pattern could help me here, aka;
public interface IDurationPricingStrategy
public decimal GetDurationPriceFor(PricingSchedule)
public interface IStylePricingStrategy
public decimal GetStylePriceFor(PricingSchedule)
This is a good way to separate things that probably will change going forward, but herein lies the rub; I can't implement one Strategy without knowing the other Strategy's "conditionals."
For example, for the IStylePricingStrategy, I implement the unlimited style pricing option like so:
public class UnlimitedStylePricingStrategy : IStylePricingStrategy
{
public decimal GetStylePriceFor(PricingSchedule)
{
if (PricingSchedule.Duration.Type == DurationType.OneYear)
{
return decimal x;
}
if (PricingSchedule.Duration.Type == DurationType.TwoYears)
{
return decimal x;
}
}
}
if I take this approach, that means if and when I have to add or change a Duration pricing type, then I have to change my StyleStrategy implementation class, which breaks SRP, and basically puts me back to square one.
It's easy if there is only one "thing" that determines the Price for the PricingSchedule, but when I have two things like this, that's where I'm hitting a wall.
Is there another pattern I can use, or somehow use the Strategy pattern differently? I feel that the problem still pulls me towards Strategy, but I'm not sure how to incorporate two Strategies instead of one.
Thanks so much!
Mike

Answer 1

I think one way might be to create an interface for the duration:
public interface IDuration
{
int GetDuration();
decimal CalculatePrice(object whatever); // int something, or whatever.
}
The have your schedule class use it:
public class PricingSchedule
{
public IDuration Duration { get; set; }
}
Then your payment style classes could use the duration like so:
public class UnlimitedStylePricingStyle : PricingStyle
{
public override void GetStylePriceFor(PricingSchedule schedule)
{
int duration = schedule.Duration.GetDuration();
//.....
}
}
The tricky one is days, I'm not sure how you would deal with that, but I would think that using an interface is your best bet here. If you need to add a new duration, you simply implement the interface IDuration.
You could then calculate the price by something like:
public override void GetStylePriceFor(PricingSchedule schedule)
{
int duration = schedule.Duration.GetDuration();
int temp = 34;
decimal result = schedule.Duration.CalculatePrice(temp);
}
Hope this give you a rough idea.