A common need in domain modelling is to specify a range - of dates, of prices, or some other numeric measure. Typically, we model this with a pair of properties, as in this example:

class MarketingCampaign
{
    DateTime? EffectiveFrom;
    DateTime? EffectiveUntil;
}

To go along with these properties, there is typically a bunch of minor logic used to ensure the range remains valid. One way is to throw an exception if an invalid range would be formed (say, if EffectiveFrom was set to a date after EffectiveUntil); another is to potentially update both ends of the range to ensure it remains valid (setting EffectiveDate to a date after EffectiveUntil would also update EffectiveUntil to the new date).

An alternative that provides more functionality and more reuse is to use an explicit Range<T> struct to declare the property:

class MarketingCampaign
{
    Range<DateTime> Effective;
}

Of course, the interesting bits are in the Range struct:

public struct Range<T>
    where T : struct, IComparable<T>
{
    public T? From { get; set; }
    public T? To { get; set; }
    public bool IsBounded { get; }
    public Range();
    public bool Contains(T value);
}

The Range struct is pretty conventional, but has a couple of features worthy of note.

Either bound may be omitted if no limit is required in that direction. In our MarketingCampaign example, To can be omitted if the end date of the campaign has not yet been determined.

Also, the sequence of the bounds is maintained - setting the value of From lower than To will update To to ensure the Range is legal, and vice versa, as follows:

public T? To
{
    get { return mTo; }
    set
    {
        mTo = value;
        if (mTo.HasValue 
            && mFrom.Value.CompareTo(mUpperBound.Value) > 0)
        {
            mFrom = mTo;
        }
    }
}

As you can see, Range is a simple helper - but one that makes our properties just that bit more expressive, capturing our domain semantics more accurately.

There are possible extensions of course. Perhaps the most obvious would be for Range to properly implement the INotifyPropertyChanged interface, exposing a PropertyChanged event for subscription. In all likelihood, the parent class would end up subscribing to this property itself in order to correctly trigger it’s own PropertyChanged events.

Another, more complicated approach would be to create a RangeProperty helper similar in intent to the Property helper discussed in my recent post Improving on POCO Properties.

Comments

blog comments powered by Disqus
Next Post
CI, Builds and NAnt  15 Jan 2010
Prior Post
Improving on POCO Collections  08 Jan 2010
Related Posts
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
When are you done?  18 Apr 2022
Fixing GitHub Authentication  28 Nov 2021
Archives
January 2010
2010