Discussion: Automatic recomposition of parameter and member aggregates

[daiplusplus]

I'm working on refactoring a codebase and I found myself switching between different representations of the same problem-solving code.

(By "aggregate" or "aggregation" I'm referring to an abstract collection of related values, such as the fields in a struct or a method's parameters)

Consider a service-pattern method that performs a sequence of web-service calls or database queries, it also accepts some parameters and builds an output result object.

We can start off with a version that only uses method parameters and no instance or static state:

public static class CentralServices
{
    public static async Task<CentralServicesReport> GenerateCentralServicesReportAsync( Uri webServiceBaseAddress, String bearerToken, Version apiVersion, DateTime? from, DateTime? to, Boolean include27BStroke6 )
    {
        // ...
    }
}

In practice, we separate out the parameters that are likely constant throughout the program's life and move those to immutable fields that are set by the constructor, which is called by the service's factory method, usually after loading the program's configuration:

public interface ICentralServices
{
    Task<CentralServicesReport> GenerateCentralServicesReportAsync( DateTime? from, DateTime? to, Boolean include27BStroke6 )
}

public class CentralServices : ICentralServices
{
    private readonly Uri baseAddress;
    private readonly String bearerToken;
    private readonly Version apiVersion;

    public CentralServices( Uri webServiceBaseAddress, String bearerToken, Version apiVersion )
    {
        // ..
    }

    public static async Task<CentralServicesReport> GenerateCentralServicesReportAsync( DateTime? from, DateTime? to, Boolean include27BStroke6 )
    {
        // ...
    }
}

Now, supposing this is a rapidly-changing piece of code and new optional or complex method parameters are added regularly, then the method could be changed to accept a single parameter object instead. This means that consumers won't need to update their code when new parameters (as object properties) are added, this also has the benefit of allowing consumers to delegate the building of parameters to code elsewhere in their application (e.g. exposing a UI to build filter criteria) simply by passing the parameter object around:

public class CentralServicesReportParameters
{
    public DateTime? From { get; set; }
    public DateTime? To   { get; set; }
    public Boolean   Include27BStroke6           { get; set; }
    public Int32     FreelanceRepairManSightings { get; set; }
    // ...
}

public interface ICentralServices
{
    public async Task<CentralServicesReport> GenerateCentralServicesReportAsync( CentralServicesReportParameters paras )
    {
        // ...
    }
}

Assuming that GenerateCentralServicesReportAsync uses the properties from paras directly instead of copying them when the method starts then the code is no-longer thread-safe as the paras object could be modified by another thread while GenerateCentralServicesReportAsync runs. A solution to this is to have an immutable CentralServicesReportParameters class along with a mutable CentralServicesReportParametersBuilder class:

public class CentralServicesReportParametersBuilder
{
    public DateTime? From { get; set; }
    public DateTime? To   { get; set; }
    public Boolean   Include27BStroke6           { get; set; }
    public Int32     FreelanceRepairManSightings { get; set; }

    public CentralServicesReportParameters Build()
    {
        return new CentralServicesReportParameters( this.From, this.To, this.Include27BStroke6, this.FreelanceRepairManSightings )
    }
}

public class CentralServicesReportParameters
{
    public DateTime? From { get; }
    public DateTime? To   { get; }
    public Boolean   Include27BStroke6           { get; }
    public Int32     FreelanceRepairManSightings { get; }

    public CentralServicesReportParameters( DateTime? from, DateTime? to, Boolean include27BStroke6, Int32 freelanceRepairManSightings )
    {
        this.From = from;
        this.To = to;
        this.Include27BStroke6 = include27BStroke6;
        this.FreelanceRepairManSightings = freelanceRepairManSightings;
    }
}

Now it's getting very repetitive and violates DRY insofar as the code is having to repeat a single aggregate in multiple representations: as a builder class, as an immutable aggregate, and as the immutable aggregates constructor parameters.

Each approach obviously has its advantages and disadvantages - but I find the difficulty and hassle of switching between the different representations of the aggregate (parameters vs class properties) a bore.

With C# record types coming out, could we see new syntax for the C# compiler to take away the repetitive work of generating parameter objects and translating them to/from method parameters. Right now I do this with T4, but that's not ideal.

What I'd like to see is the C# compiler to generate record-types and/or parameter builder types using only the current C# syntax for method parameters - or perhaps a slightly different syntax so that different subsets of a method's parameters (and the immutable fields of the parent class) are exported as their own aggregates. Referring to the original stateless method from the start of this post, we define aggregate groups in the parameters using new curly braces (line-breaks added for readability):

public static class CentralServices
{
    public static async Task<CentralServicesReport> GenerateCentralServicesReportAsync
    (
        { Uri webServiceBaseAddress, String bearerToken, Version apiVersion },
        { DateTime? from, DateTime? to, Boolean include27BStroke6 }
    )
    {
        // ...
    }
}

The compiler would then convert this code into something like this in the generated assembly:

public class CentralServicesReportGroup1 {
    public Uri baseAddress { get; }
    public String BearerToken { get; }
    public Version ApiVersion { get; }
    public CentralServicesReportGroup1( Uri webServiceBaseAddress, String bearerToken, Version apiVersion ) { ... }
}

public class CentralServicesReportGroup2 {
    public DateTime? From { get; }
    public DateTime? To   { get; }
    public Boolean   Include27BStroke6 { get; }
    public Int32 FreelanceRepairManSightings { get; }
    public CentralServicesReportGroup2( DateTime? from, DateTime? to, Boolean include27BStroke6 ) { ... }
}

public static class CentralServicesStatic
{
    public static async Task<CentralServicesReport> GenerateCentralServicesReportAsync
    (
        CentralServicesReportGroup1 group1,
        CentralServicesReportGroup2 group2
    )
    {
        // ...
    }
}

...which can then be composed into the service pattern with minimal new code and without needing to destructively refactor CentralServicesStatic by editing its original source code. A new Attribute would instruct the C# compiler to treat the type being used as an aggregate and allow both the object or individual parameters to be used by hand-written consumers:

public class CentralServices : ICentralServices
{
    private readonly CentralServicesReportGroup1 fixedState;

    public CentralServices( [ParameterAggregate] CentralServicesReportGroup1 fixedState )
    {
        this.fixedState = fixedState;
    }

    public async Task<CentralServicesReport> GenerateCentralServicesReportAsync( DateTime? from, DateTime? to, Boolean include27BStroke6 )
    {
        return await CentralServicesStatic.GenerateCentralServicesReportAsync( this.fixedState, from, to, include27BStroke6 );
    }
}

The same [ParameterAggregate] could be used by this (human-written) wrapper to also eliminate the repetition here:

public class CentralServices : ICentralServices
{
    private readonly CentralServicesReportGroup1 fixedState;

    public CentralServices( [ParameterAggregate] CentralServicesReportGroup1 fixedState )
    {
        this.fixedState = fixedState;
    }

    public async Task<CentralServicesReport> GenerateCentralServicesReportAsync( [ParameterAggregate] CentralServicesReportGroup2 paras )
    {
        return await CentralServicesStatic.GenerateCentralServicesReportAsync( this.fixedState, paras );
    }
}

Remember the C# compiler would still call CentralServices.GenerateCentralServicesReportAsync using real "stack" parameters and not by passing a heap-allocated parameter object. This also benefits writing test mock/stub/fake implementations by having them simply use the same named aggregates without needing to manually keep them in-sync with the real implementation despite
them being bona-fide C# method parameters:

public class FakeCentralServices : ICentralServices
{
    public Task<CentralServicesReport> GenerateCentralServicesReportAsync( [ParameterAggregate] CentralServicesReportGroup2 paras )
    {
        return Task.FromResult( new CentralServicesReport( ... ) );
    }
}

In short: I'd like a way in C# to represent a group of values as either parameters or class/struct members without needing to repeat myself.

[TonyValenti]

I handle this by having a Clone() member on my parameters and cloning them and then using the cloned parameters in my code. I usually have a line like this:

public  async Task DoSomething(Parameters P = null){
  P = P?.Clone() ?? new Parameters(); //Possibly Parameters.Default() as well.

  //Method body here.
}