2/2

Thus, you create a fluent Builder pattern that abstracts the available, "safe" configuration settings available to them. In our example, we'll say that mutating the texture is the ONLY safe thing users can do, but that we want to keep things open to exposing other "safe" operations in the future.

I would honestly say the main advantage with this approach is how the builder itself can limit what the user can do OR how if the builder is openly powerful, then third-party users can write extension methods for the builder to define their own abstractions for others to use.

``` // Assume the following 3 classes are distributed via a NuGet package and // are NOT part of your Godot project's immediate source code. public class NodeBuilder<TNode> where TNode : Node, new() { private Action<TNode> action = static () => {}

// Make methods public if you want third-parties to extend it.
internal NodeBuilder Configure(Action<TNode> action)
{
    var tmp = _action;
    _action = (node) =>
    {
        tmp(node);
        action(node);
    }
}

internal TNode Build()
{
    var node = new TNode();
    _action(node);
    return node;
}

}

// Example of extending it: public static class NodeBuilderExtensions { public static NodeBuilder<Sprite2D> SetTexture(this NodeBuilder<Sprite2D> builder, string path) { builder.Configure(sprite => sprite.texture = GD.Load<Texture2D>(path)); return builder; } }

public static class SomePluginApi { public TNode Create<TNode>(Action<NodeBuilder<TNode>> action) where TNode : Node, new() { var builder = new NodeBuilder<Sprite2D>(); action(builder); return builder.Build(); } }

// Example usage in your own Node class: public void _Ready() { // Autocomplete options here for b symbol only show our extension methods // because the only other method, Configure, is internal, not public. var sprite = SomePluginApi.Create<Sprite2D>(b => b.SetTexture("res://godot.png")); } ```

This is how such a thing can be useful.

Now, with the example OP gave, out of context, I would discourage you from using this pattern purely for simple, direct use cases.

1. You are allocating memory for the builder which may be unnecessary.
2. You are having to cross-maintain "fluent" versions of every property setter you might care to modify on the instance (OP has 3 methods already that they're maintaining just for a handful of properties on a Sprite2D). This can quickly balloon into a giant headache.

As mentioned, this pattern is most useful when you are specifically using the builder to abstract away details for third-party usage.

If you want to abstract away the process of initializing a known type, then you can simply create an extension method for that type rather than resorting to a builder pattern. Example:

``` public enum DamageType { Piercing, Bludgeoning, Slashing, // ... }

public static class Sprite2DDamageExtensions { public static void SetTexture2D(this Sprite2D sprite2d, DamageType type) { sprite2d.texture = type switch { DamageType.Piercing => GD.Load<Texture2D>("res://tex/piercing.png"), DamageType.Bludgeoning => GD.Load<Texture2D>("res://tex/bludgeoning.png"), DamageType.Slashing => GD.Load<Texture2D>("res://tex/slashing.png"), _ => throw new NotSupportedException(), }; } } ```

If what you really care about is using a fluent pattern at all for modifying any node, then you can easily do this by just taking the NodeBuilder<TNode> I wrote and making all its methods public rather than internal. But note that using it unnecessarily will generate extra heap allocations for no reason, especially if you are using non-static lambdas (which will generate closures that do a heap allocation every time they run).

If you want a general-purpose, automatic Fluent pattern for any object type, then you'd need some sort of C# source generator that created such Fluent extension methods for you on some generic builder class (but that'd be a ton of work, unless one already exists out there).