Як уникнути проблеми "занадто багато параметрів" в дизайні 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 # уникнути проблеми "занадто багато параметрів" без введення змінності? Чи можна використовувати структуру для читання лише для цієї мети і все ж не мати поганий дизайн 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());

У вас є досить впевнене свідчення того, що даний клас порушує Принцип єдиної відповідальності, оскільки має занадто багато залежностей. Шукайте способи переформулювання цих залежностей у кластери фасадних залежностей .

Просто змініть структуру даних параметрів на class на" 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) 

Тепер метод отримає власну копію структури. Зміни, внесені до змінної аргументу, не можуть спостерігатися методом, а зміни, які метод робить в змінній, не можуть спостерігати абонент. Ізоляція досягається без незмінності.

Плюси:

• Найпростіший у виконанні
• Найменша зміна поведінки в базовій механіці

Мінуси:

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

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

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; } 
        }
    }

Ви можете використовувати підхід у стилі будівельника, хоча залежно від складності вашого 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. Так - це схоже на програму будівельника - лише в зворотному порядку (тобто на стороні виклику замість виклику). У цьому конкретному випадку це може бути, а може і не бути кращим, ніж будівельник.

ось дещо інший від Майкі, але те, що я намагаюся зробити, це зробити так, щоб вся справа була написана якомога менше

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 є незмінним, яким він може бути, і не може бути створений безпосередньо, оскільки його конструктор за замовчуванням є приватним

Ініціалізатор не є незмінним, а лише транспортом

Використання використовує переваги ініціалізатора на Initializer (якщо ви отримаєте мій дрейф). І я можу мати за замовчуванням конструктор за замовчуванням Initializer

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());

Ще трохи коокі я знаю, але все одно спробую

Редагувати: переміщення методу створення до статичного в об'єкті параметрів і додавання делегата, який передає ініціалізатор, виводить частину коокієнності з виклику

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();

У моєму випадку параметри були навмисно модифіковані, оскільки методи встановлення не допускали всіх можливих комбінацій, а просто викривали їх загальні комбінації. Це тому, що деякі мої параметри були досить складними, а методи написання для всіх можливих випадків були б важкими та непотрібними (шалені комбінації рідко використовуються).