Как избежать проблемы «слишком много параметров» в дизайне API?

У меня есть эта функция API:

public ResultEnum DoSomeAction(string a, string b, DateTime c, OtherEnum d, 
     string e, string f, out Guid code)

Мне это не нравится Потому что порядок параметров становится излишне значимым. Становится сложнее добавлять новые поля. Труднее увидеть, что происходит вокруг. Сложнее реорганизовать метод в более мелкие части, поскольку он создает дополнительные издержки, связанные с передачей всех параметров в подфункции. Код сложнее читать.

Я пришел к наиболее очевидной идее: иметь объект, инкапсулирующий данные, и передавать его вместо передачи каждого параметра один за другим. Вот что я придумал:

public class DoSomeActionParameters
{
    public string A;
    public string B;
    public DateTime C;
    public OtherEnum D;
    public string E;
    public string F;        
}

Это уменьшило мою декларацию API до:

public ResultEnum DoSomeAction(DoSomeActionParameters parameters, out Guid code)

Ницца. Выглядит очень невинно, но мы действительно внесли огромное изменение: мы ввели изменчивость. Потому что раньше мы фактически передавали анонимный неизменяемый объект: параметры функции в стеке. Теперь мы создали новый класс, который очень изменчив. Мы создали возможность манипулировать состоянием звонящего . Это отстой. Теперь я хочу, чтобы мой объект был неизменным, что мне делать?

public class DoSomeActionParameters
{
    public string A { get; private set; }
    public string B { get; private set; }
    public DateTime C { get; private set; }
    public OtherEnum D { get; private set; }
    public string E { get; private set; }
    public string F { get; private set; }        

    public DoSomeActionParameters(string a, string b, DateTime c, OtherEnum d, 
     string e, string f)
    {
        this.A = a;
        this.B = b;
        // ... tears erased the text here
    }
}

Как видите, я на самом деле заново создал свою первоначальную проблему: слишком много параметров. Очевидно, что это не тот путь. Что я собираюсь делать? Последний вариант для достижения такой неизменности - использовать структуру «только для чтения», например:

public struct DoSomeActionParameters
{
    public readonly string A;
    public readonly string B;
    public readonly DateTime C;
    public readonly OtherEnum D;
    public readonly string E;
    public readonly string F;        
}

Это позволяет нам избегать конструкторов со слишком большим количеством параметров и достигать неизменности. На самом деле это решает все проблемы (упорядочение параметров и т. Д.). Все же:

• Все (включая FXCop и Jon Skeet) согласны с тем, что показ открытых полей плох .
• Эрик Липперт и др. Говорят, что полагаться на поля только для чтения для неизменности - ложь .

Вот тогда я запутался и решил написать вопрос: какой самый простой способ в C # избежать проблемы «слишком много параметров» без введения изменчивости? Возможно ли использовать структуру readonly для этой цели и при этом не иметь плохой дизайн API?

ПОЯСНЕНИЯ:

• Пожалуйста, примите во внимание, что нет нарушения принципа единой ответственности. В моем исходном случае функция просто записывает данные параметры в одну запись БД.
• Я не ищу конкретного решения данной функции. Я ищу обобщенный подход к таким проблемам. Я особенно заинтересован в решении проблемы «слишком много параметров» без введения изменчивости или ужасного дизайна.

ОБНОВИТЬ

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

Один стиль, включенный в каркас, обычно похож на группирование связанных параметров в связанные классы (но опять же проблематично с изменчивостью):

var request = new HttpWebRequest(a, b);
var service = new RestService(request, c, d, e);
var client = new RestClient(service, f, g);
var resource = client.RequestRestResource(); // O params after 3 objects

Используйте комбинацию компоновщика и API в стиле языка предметной области - Fluent Interface. API немного более многословен, но с intellisense его очень быстро напечатать и легко понять.

public class Param
{
        public string A { get; private set; }
        public string B { get; private set; }
        public string C { get; private set; }


  public class Builder
  {
        private string a;
        private string b;
        private string c;

        public Builder WithA(string value)
        {
              a = value;
              return this;
        }

        public Builder WithB(string value)
        {
              b = value;
              return this;
        }

        public Builder WithC(string value)
        {
              c = value;
              return this;
        }

        public Param Build()
        {
              return new Param { A = a, B = b, C = c };
        }
  }


  DoSomeAction(new Param.Builder()
        .WithA("a")
        .WithB("b")
        .WithC("c")
        .Build());

То, что у вас есть, является довольно верным признаком того, что рассматриваемый класс нарушает Принцип Единой Ответственности, потому что у него слишком много зависимостей. Ищите способы реорганизовать эти зависимости в кластеры зависимостей фасада .

Просто измените структуру данных параметров с a classна a, structи все готово.

public struct DoSomeActionParameters 
{
   public string A;
   public string B;
   public DateTime C;
   public OtherEnum D;
   public string E;
   public string F;
}

public ResultEnum DoSomeAction(DoSomeActionParameters parameters, out Guid code) 

Теперь метод получит свою собственную копию структуры. Изменения, внесенные в переменную аргумента, не могут наблюдаться методом, а изменения, вносимые методом в переменную, не могут наблюдаться вызывающей стороной. Изоляция достигается без неизменности.

Плюсы:

• Самый простой в реализации
• Наименьшее изменение поведения в основной механике

Минусы:

• Неизменность не очевидна, требует внимания разработчиков.
• Ненужное копирование для поддержания неизменности
• Занимает пространство стека

Как насчет создания класса построителя внутри вашего класса данных. Класс данных будет иметь все установщики как частные, и только строитель сможет установить их.

public class DoSomeActionParameters
    {
        public string A { get; private set; }
        public string B  { get; private set; }
        public DateTime C { get; private set; }
        public OtherEnum D  { get; private set; }
        public string E  { get; private set; }
        public string F  { get; private set; }

        public class Builder
        {
            DoSomeActionParameters obj = new DoSomeActionParameters();

            public string A
            {
                set { obj.A = value; }
            }
            public string B
            {
                set { obj.B = value; }
            }
            public DateTime C
            {
                set { obj.C = value; }
            }
            public OtherEnum D
            {
                set { obj.D = value; }
            }
            public string E
            {
                set { obj.E = value; }
            }
            public string F
            {
                set { obj.F = value; }
            }

            public DoSomeActionParameters Build()
            {
                return obj;
            }
        }
    }

    public class Example
    {

        private void DoSth()
        {
            var data = new DoSomeActionParameters.Builder()
            {
                A = "",
                B = "",
                C = DateTime.Now,
                D = testc,
                E = "",
                F = ""
            }.Build();
        }
    }

Я не программист на C #, но я считаю, что C # поддерживает именованные аргументы: (F # делает, и C # в значительной степени совместим для такого рода вещей) Это делает: http://msdn.microsoft.com/en-us/library/dd264739 .aspx # Y342

Таким образом, вызов вашего исходного кода становится:

public ResultEnum DoSomeAction( 
 e:"bar", 
 a: "foo", 
 c: today(), 
 b:"sad", 
 d: Red,
 f:"penguins")

это не займет больше места / мысли о том, что ваш объект создан и обладает всеми преимуществами того факта, что вы вообще не изменили то, что происходит в непослушной системе. Вам даже не нужно ничего перекодировать, чтобы указать, что аргументы названы

Редактировать: вот статья, которую я нашел об этом. http://www.globalnerdy.com/2009/03/12/default-and-named-parameters-in-c-40-sith-lord-in-training/ Я должен упомянуть, что C # 4.0 поддерживает именованные аргументы, 3.0 не поддерживает

Почему бы просто не создать интерфейс, обеспечивающий неизменность (то есть только получатели)?

По сути, это ваше первое решение, но вы заставляете функцию использовать интерфейс для доступа к параметру.

public interface IDoSomeActionParameters
{
    string A { get; }
    string B { get; }
    DateTime C { get; }
    OtherEnum D { get; }
    string E { get; }
    string F { get; }              
}

public class DoSomeActionParameters: IDoSomeActionParameters
{
    public string A { get; set; }
    public string B { get; set; }
    public DateTime C { get; set; }
    public OtherEnum D { get; set; }
    public string E { get; set; }
    public string F { get; set; }        
}

и объявление функции становится:

public ResultEnum DoSomeAction(IDoSomeActionParameters parameters, out Guid code)

Плюсы:

• Не имеет проблемы с пространством стека, как structрешение
• Естественное решение с использованием языковой семантики
• Неизменность очевидна
• Гибкость (потребитель может использовать другой класс, если он хочет)

Минусы:

• Некоторая повторяющаяся работа (одни и те же объявления в двух разных сущностях)
• Разработчик должен угадать, что DoSomeActionParametersэто класс, который может быть сопоставлен сIDoSomeActionParameters

Я знаю, что это старый вопрос, но я решил добавить свое предложение, поскольку мне просто нужно было решить ту же проблему. Теперь, конечно, моя проблема немного отличалась от вашей, так как у меня было дополнительное требование не желать, чтобы пользователи могли сами создавать этот объект (вся гидратация данных происходила из базы данных, поэтому я мог отбросить все конструкции изнутри). Это позволило мне использовать приватный конструктор и следующий шаблон;

    public class ExampleClass
    {
        //create properties like this...
        private readonly int _exampleProperty;
        public int ExampleProperty { get { return _exampleProperty; } }

        //Private constructor, prohibiting construction outside of this class
        private ExampleClass(ExampleClassParams parameters)
        {                
            _exampleProperty = parameters.ExampleProperty;
            //and so on... 
        }

        //The object returned from here will be immutable
        public ExampleClass GetFromDatabase(DBConnection conn, int id)
        {
            //do database stuff here (ommitted from example)
            ExampleClassParams parameters = new ExampleClassParams()
            {
                ExampleProperty = 1,
                ExampleProperty2 = 2
            };

            //Danger here as parameters object is mutable

            return new ExampleClass(parameters);    

            //Danger is now over ;)
        }

        //Private struct representing the parameters, nested within class that uses it.
        //This is mutable, but the fact that it is private means that all potential 
        //"damage" is limited to this class only.
        private struct ExampleClassParams
        {
            public int ExampleProperty { get; set; }
            public int AnotherExampleProperty { get; set; }
            public int ExampleProperty2 { get; set; }
            public int AnotherExampleProperty2 { get; set; }
            public int ExampleProperty3 { get; set; }
            public int AnotherExampleProperty3 { get; set; }
            public int ExampleProperty4 { get; set; }
            public int AnotherExampleProperty4 { get; set; } 
        }
    }

Вы можете использовать подход в стиле Builder, хотя, в зависимости от сложности вашего DoSomeActionметода, это может быть тяжеловес. Что-то вроде этого:

public class DoSomeActionParametersBuilder
{
    public string A { get; set; }
    public string B { get; set; }
    public DateTime C { get; set; }
    public OtherEnum D { get; set; }
    public string E { get; set; }
    public string F { get; set; }

    public DoSomeActionParameters Build()
    {
        return new DoSomeActionParameters(A, B, C, D, E, F);
    }
}

public class DoSomeActionParameters
{
    public string A { get; private set; }
    public string B { get; private set; }
    public DateTime C { get; private set; }
    public OtherEnum D { get; private set; }
    public string E { get; private set; }
    public string F { get; private set; }

    public DoSomeActionParameters(string a, string b, DateTime c, OtherEnum d, string e, string f)
    {
        A = a;
        // etc.
    }
}

// usage
var actionParams = new DoSomeActionParametersBuilder
{
    A = "value for A",
    C = DateTime.Now,
    F = "I don't care for B, D and E"
}.Build();

result = foo.DoSomeAction(actionParams, out code);

В дополнение к ответу Манджи - вы также можете разделить одну операцию на несколько меньших. Для сравнения:

 BOOL WINAPI CreateProcess(
   __in_opt     LPCTSTR lpApplicationName,
   __inout_opt  LPTSTR lpCommandLine,
   __in_opt     LPSECURITY_ATTRIBUTES lpProcessAttributes,
   __in_opt     LPSECURITY_ATTRIBUTES lpThreadAttributes,
   __in         BOOL bInheritHandles,
   __in         DWORD dwCreationFlags,
   __in_opt     LPVOID lpEnvironment,
   __in_opt     LPCTSTR lpCurrentDirectory,
   __in         LPSTARTUPINFO lpStartupInfo,
   __out        LPPROCESS_INFORMATION lpProcessInformation
 );

и

 pid_t fork()
 int execvpe(const char *file, char *const argv[], char *const envp[])
 ...

Для тех, кто не знает POSIX, создание ребенка может быть таким простым:

pid_t child = fork();
if (child == 0) {
    execl("/bin/echo", "Hello world from child", NULL);
} else if (child != 0) {
    handle_error();
}

Каждый выбор дизайна представляет собой компромисс по поводу того, какие операции он может выполнять.

PS. Да - это похоже на строителя - только наоборот (т.е. на стороне вызываемого абонента вместо вызывающего абонента). Это может или не может быть лучше, чем строитель в этом конкретном случае.

Это немного отличается от Mikeys, но я пытаюсь сделать так, чтобы все было как можно меньше писать.

public class DoSomeActionParameters
{
    readonly string _a;
    readonly int _b;

    public string A { get { return _a; } }

    public int B{ get { return _b; } }

    DoSomeActionParameters(Initializer data)
    {
        _a = data.A;
        _b = data.B;
    }

    public class Initializer
    {
        public Initializer()
        {
            A = "(unknown)";
            B = 88;
        }

        public string A { get; set; }
        public int B { get; set; }

        public DoSomeActionParameters Create()
        {
            return new DoSomeActionParameters(this);
        }
    }
}

DoSomeActionParameters является неизменным, поскольку он может быть и не может быть создан напрямую, так как его конструктор по умолчанию является частным

Инициализатор не неизменный, а только транспорт

Использование использует инициализатор на Инициализаторе (если вы меня поняли) И у меня могут быть значения по умолчанию в конструкторе Инициализатора по умолчанию

DoSomeAction(new DoSomeActionParameters.Initializer
            {
                A = "Hello",
                B = 42
            }
            .Create());

Параметры здесь будут необязательными, если вы хотите, чтобы некоторые из них были обязательными, вы можете поместить их в конструктор по умолчанию для Initializer.

И валидация может идти в методе Create

public class Initializer
{
    public Initializer(int b)
    {
        A = "(unknown)";
        B = b;
    }

    public string A { get; set; }
    public int B { get; private set; }

    public DoSomeActionParameters Create()
    {
        if (B < 50) throw new ArgumentOutOfRangeException("B");

        return new DoSomeActionParameters(this);
    }
}

Так что теперь это выглядит

DoSomeAction(new DoSomeActionParameters.Initializer
            (b: 42)
            {
                A = "Hello"
            }
            .Create());

Еще немного куки я знаю, но все равно попробую

Редактирование: перемещение метода create в static в объекте параметров и добавление делегата, который проходит инициализатор, снимает некоторую изворотливость вызова

public class DoSomeActionParameters
{
    readonly string _a;
    readonly int _b;

    public string A { get { return _a; } }
    public int B{ get { return _b; } }

    DoSomeActionParameters(Initializer data)
    {
        _a = data.A;
        _b = data.B;
    }

    public class Initializer
    {
        public Initializer()
        {
            A = "(unknown)";
            B = 88;
        }

        public string A { get; set; }
        public int B { get; set; }
    }

    public static DoSomeActionParameters Create(Action<Initializer> assign)
    {
        var i = new Initializer();
        assign(i)

        return new DoSomeActionParameters(i);
    }
}

Итак, звонок теперь выглядит так

DoSomeAction(
        DoSomeActionParameters.Create(
            i => {
                i.A = "Hello";
            })
        );

Используйте структуру, но вместо открытых полей имейте открытые свойства:

• Все (включая FXCop и Jon Skeet) согласны с тем, что обнародование открытых полей - это плохо.

Jon и FXCop будут удовлетворены, потому что вы выставляете свойства, а не поля.

• Эрик Липперт и др. Говорят, что полагаться на поля только для чтения для неизменности - ложь.

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

    private bool propC_set=false;
    private date pC;
    public date C {
        get{
            return pC;
        }
        set{
            if (!propC_set) {
               pC = value;
            }
            propC_set = true;
        }
    }

Один неизменный объект (значение может быть установлено, но не изменено). Работает для значений и ссылочных типов.

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

class MagicPerformer
{
    public int Param1 { get; set; }
    public string Param2 { get; set; }
    public DateTime Param3 { get; set; }

    public MagicPerformer SetParam1(int value) { this.Param1 = value; return this; }
    public MagicPerformer SetParam2(string value) { this.Param2 = value; return this; }
    public MagicPerformer SetParam4(DateTime value) { this.Param3 = value; return this; }

    public void DoMagic() // Uses all the parameters and does the magic
    {
    }
}

И использовать:

new MagicPerformer().SeParam1(10).SetParam2("Yo!").DoMagic();

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