Here is a base class for some code that i have written once too many in my life: (In case you’re an early adaptor (.Net 4.0) you may want to use System.Tuple<T1> as base class)

public class ValueType<t> : IComparable, IComparable<valueType<t>>, IEquatable<valueType<t>>
 where T : IComparable<t>
{
 protected T Value { get; private set; }public ValueType(T value)
 {
  Value = value;
 }

 public override int GetHashCode()
 {
  return Value.GetHashCode();
 }

 public override string ToString()
 {
  return Value.ToString();
 }

 public override bool Equals(object obj)
 {
  return Equals(obj as ValueType<t>);
 }

 public bool Equals(ValueType<t> other)
 {
  return Compare(this, other) == 0;
 }

 public int CompareTo(object obj)
 {
  return CompareTo(this, obj as ValueType<t>);
 }

 public int CompareTo(ValueType<t> other)
 {
  return Compare(this, other);
 }

 static int Compare(ValueType<t> instance1, ValueType<t> instance2)
 {
  if (ReferenceEquals(instance1, instance2)) return 0;
  if (ReferenceEquals(instance1, null)) return -1;
  if (ReferenceEquals(instance2, null)) return 1;

  if (ReferenceEquals(instance1.Value, instance2.Value)) return 0;
  if (ReferenceEquals(instance1.Value, null)) return -1;
  if (ReferenceEquals(instance2.Value, null)) return 1;

  return instance1.Value.CompareTo(instance2.Value);
 }

 public static bool operator ==(ValueType<t> instance1, ValueType<t> instance2)
 {
  return Compare(instance1, instance2) == 0;
 }

 public static bool operator !=(ValueType<t> instance1, ValueType<t> instance2)
 {
  return !(instance1 == instance2);
 }

 public static bool operator <(ValueType<t> instance1, ValueType<t> instance2)
 {
   return Compare(instance1, instance2) < 0;
 }

 public static bool operator >(ValueType<t> instance1, ValueType<t> instance2)
 {
   return Compare(instance1, instance2) > 0;
 }
}

Lately i have done quite a bit of charting. Very often the X-axis is populated with a series of numbers or dates. This can be as simple as: (My very little DSL in Jeremy D. Miller Style)

[Test] public void ShouldBeAbleToGetSeriesOfNumbers()
{
 // Arrange
 var series = 3.To(5);

 // Act
 var elements = series.Elements;

 // Assert
 var expected = new[] { 3, 4, 5 };
 CollectionAssert.AreEqual(expected, elements);
}

[Test] public void ShouldBeAbleToGetSeriesOfDays()
{
 // Arrange
 var now = DateTime.Now.Date;
 var twoDaysLater = now.AddDays(2);
 var series = now.To(twoDaysLater);

 // Act
 var elements = series.Elements;

 // Assert
 var expectedDays = new[] { now, now.AddDays(1), now.AddDays(2) };
 CollectionAssert.AreEqual(expectedDays, elements);
}

And here is the code that makes these tests pass:

public static class Series
{
 public static Series<int> To(this int from, int to)
 {
  return Create(from, to);
 }

 public static Series<dateTime> To(this DateTime from, DateTime to)
 {
  return Create(from, to);
 }

 public static Series<dateTime> Create(DateTime from, DateTime to)
 {
  return new Series<dateTime>(from.Date, to.Date, d => d.AddDays(1));
 }

 public static Series<dateTime> Create(DateTime from, int numberOfDays)
 {
  return Create(from.Date, from.Date.AddDays(numberOfDays));
 }

 public static Series<int> Create(int from, int to)
 {
  return new Series<int>(from, to, n => n + 1);
 }

 public static Series<int> Create(int from, int to, int stepSize)
 {
  return new Series<int>(from, to, n => n + stepSize);
 }
}

public class Series<t> : IEnumerable<t> where T : IComparable
{
 public T From { get; private set; }
 public T To { get; private set; }
 public Func<t, T> Step { get; private set; }

 public Series(T from, T to, Func<t, T> step)
 {
  From = from;
  To = to;
  Step = step;
 }

 public IEnumerable<t> Elements
 {
  get
  {
   var current = From;
   while (current.CompareTo(To) <= 0)
   {
    yield return current;
    current = Step(current);
   }
  }
 }

 public IEnumerator<t> GetEnumerator()
 {
  return Elements.GetEnumerator();
 }

 IEnumerator IEnumerable.GetEnumerator()
 {
  return GetEnumerator();
 }
}

Here is another problem i’ve seen people solve once too many: Append one array to another. STOP. Revisit the problem. Can’t you simply use List<T> and move on to solving actual business problems? In case you really can’t get rid of the arrays read the following:

Given()
{
 source = new[] { SourceElement };
 destination = new[] { DestinationElement };
}

When()
{
 source.AppendTo(ref destination);
}

ThenTheDestinationShouldStillHaveTheDestinationElement()
{
 Assert.AreEqual(DestinationElement, destination[0]);
}

ThenTheDestinationShouldHaveBeenExtendedWithTheSourceElement()
{
 Assert.AreEqual(SourceElement, destination[1]);
}

And here is the code which satisfies the requirements:

public static class Extensions
{
 public static void AppendTo<t>(this T[] sourceArray, ref T[] destinationArray)
 {
  var sourceLength = sourceArray.Length;
  var destinationLength = destinationArray.Length;
  var extendedLength = destinationLength + sourceLength;
  Array.Resize(ref destinationArray, extendedLength);
  Array.Copy(sourceArray, 0, destinationArray, destinationLength, sourceLength);
 }
}

Perhaps it’s time to start (or does it exist already, cause i can’t find it) an open-source project with extension methods.

A common reason to take advantage of extension methods is to enhance readability (think fluent interfaces). My team uses the specification pattern regularly and in case a requirement says something like “if the player has reached level 10 a message should be displayed” they would implement it as:

if (new HasReachedLevel(10).IsSatisfiedBy(player))
{
 view.DisplayMessage("Congratulations! You have reached level 10.");
}

Pretty good but did you notice that they changed the order of player and level in their (code) story? With the aid of an extension method we can express this requirement as:

if (player.Satisfies(new HasReachedLevel(10)))
{
 view.DisplayMessage("Congratulations! You have reached level 10.");
}

Here is the extension method that allows you to express the requirement in this way:

public static bool Satisfies<t>(this T candidate, ISpecification<t> specification)
{
 return specification.IsSatisfiedBy(candidate);
}

Here is an example that demonstrates how strick mocks lead to overspecification. Imagine that we are creating a simple screen in a Passive View architecture. The first feature that we implement is displaying the message “edit” when the user clicks the edit button:

[Fact] public void ShouldDisplayEditClickMessage()
{
 // Establish context
 MockRepository mockRepository = new MockRepository();
 IView view = mockRepository.StrictMock<iview>();
 Expect.Call(delegate { view.EditClick += null; }).IgnoreArguments();
 mockRepository.Replay(view);

 // Create sut
 Presenter sut = new Presenter(view);

 // Setup expectations
 mockRepository.BackToRecord(view, BackToRecordOptions.Expectations);
 Expect.Call(delegate { view.DisplayClickMessage("edit"); });
 mockRepository.ReplayAll();

 // Exercise
 RhinoMocksExtensions
  .GetEventRaiser(view, delegate(IView v) { v.EditClick += null; })
  .Raise(view, EventArgs.Empty);

 // Verify
 mockRepository.VerifyAll();
}

And now we add the feature that displays the message “save” whenever the user clicks on the save button:

[Fact] public void ShouldDisplaySaveClickMessage()
{
 // Establish context
 MockRepository mockRepository = new MockRepository();
 IView view = mockRepository.StrictMock<iview>();
 Expect.Call(delegate { view.EditClick += null; }).IgnoreArguments();
 Expect.Call(delegate { view.SaveClick += null; }).IgnoreArguments();
 mockRepository.Replay(view);

 // Create sut
 Presenter sut = new Presenter(view);

 // Setup expectations
 mockRepository.BackToRecord(view, BackToRecordOptions.Expectations);
 Expect.Call(delegate { view.DisplayClickMessage("save"); });
 mockRepository.ReplayAll();

 // Exercise
 RhinoMocksExtensions
  .GetEventRaiser(view, delegate(IView v) { v.SaveClick += null; })
  .Raise(view, EventArgs.Empty);

  // Verify
  mockRepository.VerifyAll();
 }
}

Although we implemented the feature correctly, and left the code of the first feature untouched, we notice that our ShouldDisplayEditClickMessage test fails because it is not expecting a subscription to the SaveClick event. Imho, this way of testing is a testing anti-pattern.

A while ago i presented the EffectivityManager. Having used this class for a while i have decided to rename it to Temporal<T>. The implementation of IList<T> is not required anymore because a user is typically only interested in a specific effectivity, not the evolution of the effectivities.

/// <summary>
/// Represents an element that changes over time.
/// It consists out of effectivities of that element that are effective in different periods.
/// </summary>
public interface ITemporal<t>
{
 /// <summary>
 /// Modifies the element from the given date.
 /// </summary>
 /// <param name="element"></param>
 /// <param name="from"></param>
 /// <returns></returns>
 void Modify(T element, DateTime from);

 /// <summary>
 /// Gets the effectivity that is valid on the given date.
 /// </summary>
 /// <param name="validityDate">The validity date.</param>
 /// <returns></returns>
 IEffectivity<t> GetSnapshot(DateTime validityDate);

 /// <summary>
 /// Tries to get the effectivity that is valid on the given date.
 /// </summary>
 /// <param name="validityDate"></param>
 /// <param name="effectivity"></param>
 /// <returns></returns>
 bool TryGetSnapshot(DateTime validityDate, out IEffectivity<t> effectivity);
}

In the implementation i have added a constructor that accepts a DiscreteValuesGenerator<DateTime> which makes it possible to create Periods with a resolution of a day instead of seconds.