Свойства C# установки Fluently и методы объединения в цепочку

Я бы использовал метод расширения Init, потому что U всегда может играть с делегатом. Черт, вы всегда можете объявить методы расширения, которые принимают выражения и даже подыгрывают выражениям (сохраните их на потом, измените, что угодно) Таким образом Вы можете легко сохранить группы по умолчанию, например:

Create<Paint>(() => new Paint{p.Red = 0.3, p.Blue = 0.2, p.Green = 0.1}).
Init(p => p.Mix().Stir())

Таким образом Вы можете использовать все действия (или функции) и стандартные инициализаторы кеширования в качестве цепочек выражений на будущее?

Если вы действительно хотите иметь возможность цепочки настроек свойств без необходимости писать тонну кода, одним из способов сделать это может быть использование генерации кода (CodeDom). Вы можете использовать Reflection для получения списка изменяемых свойств, а затем сгенерировать класс fluent builder с конечным методом Build(), который возвращает класс, который вы пытаетесь создать.

Я собираюсь пропустить весь шаблонный материал о том, как зарегистрировать пользовательский инструмент - это довольно легко найти в документации, но все равно долго, и я не думаю, что добавлю много нового, включив его. Однако я покажу вам, что я думаю о кодегене.

public static class PropertyBuilderGenerator
{
    public static CodeTypeDeclaration GenerateBuilder(Type destType)
    {
        if (destType == null)
            throw new ArgumentNullException("destType");
        CodeTypeDeclaration builderType = new
            CodeTypeDeclaration(destType.Name + "Builder");
        builderType.TypeAttributes = TypeAttributes.Public;
        CodeTypeReference destTypeRef = new CodeTypeReference(destType);
        CodeExpression resultExpr = AddResultField(builderType, destTypeRef);
        PropertyInfo[] builderProps = destType.GetProperties(
            BindingFlags.Instance | BindingFlags.Public);
        foreach (PropertyInfo prop in builderProps)
        {
            AddPropertyBuilder(builderType, resultExpr, prop);
        }
        AddBuildMethod(builderType, resultExpr, destTypeRef);
        return builderType;
    }

    private static void AddBuildMethod(CodeTypeDeclaration builderType,
        CodeExpression resultExpr, CodeTypeReference destTypeRef)
    {
        CodeMemberMethod method = new CodeMemberMethod();
        method.Attributes = MemberAttributes.Public | MemberAttributes.Final;
        method.Name = "Build";
        method.ReturnType = destTypeRef;
        method.Statements.Add(new MethodReturnStatement(resultExpr));
        builderType.Members.Add(method);
    }

    private static void AddPropertyBuilder(CodeTypeDeclaration builderType,
        CodeExpression resultExpr, PropertyInfo prop)
    {
        CodeMemberMethod method = new CodeMemberMethod();
        method.Attributes = MemberAttributes.Public | MemberAttributes.Final;
        method.Name = prop.Name;
        method.ReturnType = new CodeTypeReference(builderType.Name);
        method.Parameters.Add(new CodeParameterDeclarationExpression(prop.Type,
            "value"));
        method.Statements.Add(new CodeAssignStatement(
            new CodePropertyReferenceExpression(resultExpr, prop.Name),
            new CodeArgumentReferenceExpression("value")));
        method.Statements.Add(new MethodReturnStatement(
            new CodeThisExpression()));
        builderType.Members.Add(method);
    }

    private static CodeFieldReferenceExpression AddResultField(
        CodeTypeDeclaration builderType, CodeTypeReference destTypeRef)
    {
        const string fieldName = "_result";
        CodeMemberField resultField = new CodeMemberField(destTypeRef, fieldName);
        resultField.Attributes = MemberAttributes.Private;
        builderType.Members.Add(resultField);
        return new CodeFieldReferenceExpression(
            new CodeThisReferenceExpression(), fieldName);
    }
}

Я думаю, что это должно почти сделать это - очевидно, что это не проверено, но вы пойдете отсюда так: вы создаете codegen (наследующий от BaseCodeGeneratorWithSite), который компилирует CodeCompileUnit, заполненный списком типов. Этот список берется из типа файла, который вы регистрируете в инструменте - в данном случае я бы, вероятно, просто сделал его текстовым файлом с разделенным на строки списком типов, для которых вы хотите сгенерировать код сборщика. Пусть инструмент просканирует его, загрузит типы (возможно, сначала придется загрузить сборки) и сгенерирует байткод.

Это сложно, но не так сложно, как кажется, и когда вы закончите, вы сможете написать код, подобный этому:

Paint p = new PaintBuilder().Red(0.4).Blue(0.2).Green(0.1).Build().Mix.Stir();

Что, как я полагаю, почти точно то, что вы хотите. Все, что вам нужно сделать, чтобы вызвать генерацию кода, это зарегистрировать инструмент с пользовательским расширением (скажем, .buildertypes), поместить файл с этим расширением в ваш проект и поместить в него список типов:

MyCompany.MyProject.Paint
MyCompany.MyProject.Foo
MyCompany.MyLibrary.Bar

И так далее. Когда вы сохраните, он автоматически сгенерирует нужный вам файл кода, поддерживающий написание утверждений, подобных приведенному выше.

Я уже использовал этот подход для очень запутанной системы обмена сообщениями с несколькими сотнями различных типов сообщений. Это занимало слишком много времени, чтобы постоянно конструировать сообщение, устанавливать кучу свойств, отправлять его по каналу, получать от канала, сериализовать ответ и т.д. Использование codegen значительно упростило работу, поскольку позволило мне создать один класс обмена сообщениями, который принимал все отдельные свойства в качестве аргументов и выдавал ответ нужного типа. Это не то, что я бы рекомендовал всем, но когда вы имеете дело с очень большими проектами, иногда нужно начинать изобретать свой собственный синтаксис!

Я бы подумал об этом так:

По сути, вы хотите, чтобы ваш последний метод в цепочке возвращал Bucket. В вашем случае, я думаю, вы хотите, чтобы этот метод был Mix (), так как после этого вы можете Stir () ведро

public class BucketBuilder
{
    private int _red = 0;
    private int _green = 0;
    private int _blue = 0;

    public Bucket Mix()
    {
        Bucket bucket = new Bucket(_paint);
        bucket.Mix();
        return bucket;
    }
}

Таким образом, вам нужно установить хотя бы один цвет перед вызовом Mix (). Давайте сделаем это с помощью некоторых синтаксических интерфейсов.

public interface IStillNeedsMixing : ICanAddColours
{
     Bucket Mix();
}

public interface ICanAddColours
{
     IStillNeedsMixing Red(int red);
     IStillNeedsMixing Green(int green);
     IStillNeedsMixing Blue(int blue);
}

И давайте применим их к BucketBuilder.

public class BucketBuilder : IStillNeedsMixing, ICanAddColours
{
    private int _red = 0;
    private int _green = 0;
    private int _blue = 0;

    public IStillNeedsMixing Red(int red)
    {
         _red += red;
         return this;
    }

    public IStillNeedsMixing Green(int green)
    {
         _green += green;
         return this;
    }

    public IStillNeedsMixing Blue(int blue)
    {
         _blue += blue;
         return this;
    }

    public Bucket Mix()
    {
        Bucket bucket = new Bucket(new Paint(_red, _green, _blue));
        bucket.Mix();
        return bucket;
    }
}

Теперь вам нужно начальное статическое свойство для запуска цепочки

public static class CreateBucket
{
    public static ICanAddColours UsingPaint
    {
        return new BucketBuilder();
    }
}

И это почти все, теперь у вас есть свободный интерфейс с дополнительными параметрами RGB (если вы вводите хотя бы один) в качестве бонуса.

CreateBucket.UsingPaint.Red(0.4).Green(0.2).Mix().Stir();

Проблема с Fluent Interfaces в том, что их не так просто собрать, но разработчику легко кодировать их, и они очень расширяемы. Если вы хотите добавить к этому флаг Matt / Gloss, не меняя весь код вызова, это легко сделать.

Кроме того, если провайдер вашего API изменяет все, что находится под вами, вам нужно только переписать этот единственный фрагмент кода; весь код вызова может оставаться прежним.