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; }
        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.


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
The Liskov substitution principle goes both ways  21 Mar 2020
Avoid hardcoded wait times  26 May 2018
Guaranteed Progression  19 May 2018
Prefer declarative method names  03 Feb 2018
Using Premeditation  27 Jan 2018
With Relocation  20 Jan 2018
Using Consolidation  13 Jan 2018
Using Semantic Types  06 Jan 2018
Using Extension Methods  30 Dec 2017
Error Methods  25 Nov 2017
More smart-code posts »
January 2010