Mandatory builder methods / builder constructor parameters

[TijmenUU]

Hi,

I really like what you have build here and most use cases are nicely covered. However, in the past I have made builders use constructors with parameters for properties on the to-be-constructed object that are "required" to construct a sane object. Not making the default constructor available for the builder forced developers to to think about what they are constructing. Sometimes a named constructor like CreateWithRandomValues helped signal that the test really did not care about (parts of) the content of the object, whilst named constructors like CreateForSpecificUseCaseX helped with removing duplicate builder usage. In some cases there really was no sane default nor sensible shared named constructor possible. In those cases the builder simply had the mandatory properties for the to-be-constructed object as constructor parameters.

Did I miss something in the README or how would you deal with this?

[pmrogala]

I'm not sure I understand the problem, you want to force the builder to have constructor with required fields for the given object the builder is constructing?
if yes, you can use the PreBuild method and put there some default set up of the required fields:
https://github.com/pmrogala/Buildenator#%EF%B8%8F-customizable--extensible
Or you can make it even more automatic with "Default[FieldName]" behavior
https://github.com/pmrogala/Buildenator#-default-field-initialization

But anyway it's something I can add as an additional feature.

If I don't understand what you mean - could you provide some code sample of what is your target state you want to achieve?

[TijmenUU]

Thanks for the quick response. Sure, here is a simplified code example:

public class Dto
{
    [JsonConstructor]
    private Dto() { }

    public Dto(int lineNumber, string activity)
    {
        LineNumber = lineNumber;
        Activity = activity;
    }

    public int LineNumber { get; set; }
    public string Activity { get; set; } = string.Empty;
    public List<string> Tags { get; set; } = [];
}

public class DtoBuilder
{
    private int lineNumber;
    private string activity;
    private List<string> tags;

    public DtoBuilder(int lineNumber, string activity)
    {
        this.lineNumber = lineNumber;
        this.activity = activity;
        tags = [];
    }

    public DtoBuilder WithLineNumber(int value)
    {
        lineNumber = value;
        return this;
    }

    public DtoBuilder WithActivity(string value)
    {
        activity = value;
        return this;
    }

    public DtoBuilder WithTag(params string[] values)
    {
        tags.AddRange(values);
        return this;
    }

    public Dto Build() => new(lineNumber: lineNumber, activity: activity) { Tags = tags };
}

The key thing here is that a Dto object under normal circumstances should not have default values, nor do randomized values make much sense in this case. Hence the constructor requires these two things as arguments. For the builder you get a similar problem: constructing a Dto with default values for all properties makes little sense, thus supplying the required values through the constructor seems to make the most sense.

Now you could say that the developer should simply know what a valid Dto is and thus knows what properties are "mandatory" to set using the builder. What I have found, however, is that in a large enough codebase and/or with new (junior) developers this can be non obvious. That is why I really like constructors with parameters, they communicate the intended use.

Named constructors can be helpful to communicate intent, but having a parameterless constructor available usually undercuts this somewhat.

Obviously this boils down to "skill issues" and I am not sure if this, somewhat niche, problem should be solved by your library. Perhaps having the option to make the builder constructor(s) private would solve this by forcing the user to specify named constructors, i.e. :

[MakeBuilder(typeof(Dto), GeneratePrivateConstructor = true)]
public partial class DtoBuilder
{
    public static DtoBuilder Create(int lineNumber, string activity) => new().WithLineNumber(lineNumber).WithActivity(activity);
}

[pmrogala]

Idea makes sense, the forced parameters to the builder weren't considered because the original purpose of the library was to help with unit testing, and in unit testing you don't need to be that strict.
But in the case you showed for sure it sounds like a good idea, I'll move it to the issues tracker.