Home/ Questions/Q 62313
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T18:27:23+00:00

I’m creating a series of builders to clean up the syntax which creates domain

  • 0

I’m creating a series of builders to clean up the syntax which creates domain classes for my mocks as part of improving our overall unit tests. My builders essentially populate a domain class (such as a Schedule) with some values determined by invoking the appropriate WithXXX and chaining them together.

I’ve encountered some commonality amongst my builders and I want to abstract that away into a base class to increase code reuse. Unfortunately what I end up with looks like:

public abstract class BaseBuilder<T,BLDR> where BLDR : BaseBuilder<T,BLDR>                                            where T : new() {     public abstract T Build();      protected int Id { get; private set; }     protected abstract BLDR This { get; }      public BLDR WithId(int id)     {         Id = id;         return This;     } }

Take special note of the protected abstract BLDR This { get; }.

A sample implementation of a domain class builder is:

public class ScheduleIntervalBuilder :     BaseBuilder<ScheduleInterval,ScheduleIntervalBuilder> {     private int _scheduleId;     // ...      // UG! here's the problem:     protected override ScheduleIntervalBuilder This     {         get { return this; }     }      public override ScheduleInterval Build()     {         return new ScheduleInterval         {             Id = base.Id,             ScheduleId = _scheduleId                     // ...         };     }      public ScheduleIntervalBuilder WithScheduleId(int scheduleId)     {         _scheduleId = scheduleId;         return this;     }      // ... }

Because BLDR is not of type BaseBuilder I cannot use return this in the WithId(int) method of BaseBuilder.

Is exposing the child type with the property abstract BLDR This { get; } my only option here, or am I missing some syntax trick?

Update (since I can show why I’m doing this a bit more clearly):

The end result is to have builders that build profiled domain classes that one would expect to retrieve from the database in a [programmer] readable format. There’s nothing wrong with…

mock.Expect(m => m.Select(It.IsAny<int>())).Returns(     new Schedule     {         ScheduleId = 1         // ...     } );

as that’s pretty readable already. The alternative builder syntax is:

mock.Expect(m => m.Select(It.IsAny<int>())).Returns(     new ScheduleBuilder()         .WithId(1)         // ...         .Build() );

the advantage I’m looking for out of using builders (and implementing all these WithXXX methods) is to abstract away complex property creation (automatically expand our database lookup values with the correct Lookup.KnownValues without hitting the database obviously) and having the builder provide commonly reusable test profiles for domain classes…

mock.Expect(m => m.Select(It.IsAny<int>())).Returns(     new ScheduleBuilder()         .AsOneDay()         .Build() );
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. All I can say is that if there is a way of doing it, I want to know about it too – I use exactly this pattern in my Protocol Buffers port. In fact, I’m glad to see that someone else has resorted to it – it means we’re at least somewhat likely to be right!

    • 0