Como evitar o problema de "muitos parâmetros" no design da API?

Eu tenho esta função de API:

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

Eu não gosto disso Porque a ordem dos parâmetros se torna desnecessariamente significativa. Torna-se mais difícil adicionar novos campos. É mais difícil ver o que está sendo repassado. É mais difícil refatorar o método em partes menores, porque isso cria outra sobrecarga na passagem de todos os parâmetros nas sub-funções. O código é mais difícil de ler.

Tive a idéia mais óbvia: ter um objeto encapsulando os dados e repassá-los ao invés de passar cada parâmetro um por um. Aqui está o que eu vim com:

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

Isso reduziu minha declaração da API para:

public ResultEnum DoSomeAction(DoSomeActionParameters parameters, out Guid code)

Agradável. Parece muito inocente, mas na verdade introduzimos uma grande mudança: introduzimos a mutabilidade. Porque o que estávamos fazendo anteriormente era realmente passar um objeto imutável anônimo: parâmetros de função na pilha. Agora criamos uma nova classe que é muito mutável. Criamos a capacidade de manipular o estado do chamador . Isso é péssimo. Agora eu quero meu objeto imutável, o que faço?

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

Como você pode ver, eu realmente recriei meu problema original: muitos parâmetros. É óbvio que esse não é o caminho a seguir. O que eu vou fazer? A última opção para alcançar essa imutabilidade é usar uma estrutura "somente leitura" como esta:

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

Isso nos permite evitar construtores com muitos parâmetros e obter imutabilidade. Na verdade, ele corrige todos os problemas (ordenação de parâmetros etc.). Ainda:

• Todos (incluindo FXCop e Jon Skeet) concordam que a exposição de campos públicos é ruim .
• Eric Lippert e colaboradores afirmam que confiar em campos somente para imutabilidade é uma mentira .

Foi quando fiquei confuso e decidi escrever esta pergunta: Qual é a maneira mais direta em C # de evitar o problema de "muitos parâmetros" sem introduzir mutabilidade? É possível usar uma estrutura somente leitura para esse fim e ainda não ter um design de API ruim?

ESCLARECIMENTOS:

• Por favor, assuma que não há violação do princípio de responsabilidade única. No meu caso original, a função apenas grava parâmetros fornecidos em um único registro de banco de dados.
• Não estou procurando uma solução específica para a função especificada. Estou buscando uma abordagem generalizada para esses problemas. Estou especificamente interessado em resolver o problema de "muitos parâmetros" sem introduzir mutabilidade ou um design terrível.

ATUALIZAR

As respostas fornecidas aqui têm diferentes vantagens / desvantagens. Portanto, eu gostaria de converter isso em um wiki da comunidade. Acho que cada resposta com amostra de código e Prós / Contras seria um bom guia para problemas semelhantes no futuro. Agora estou tentando descobrir como fazê-lo.

Um estilo adotado nas estruturas é geralmente como agrupar parâmetros relacionados em classes relacionadas (mas mais uma vez problemático com mutabilidade):

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

Use uma combinação da API do estilo do construtor e do idioma específico do domínio - Interface Fluente. A API é um pouco mais detalhada, mas com o intellisense é muito rápido digitar e fácil de entender.

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

O que você tem lá é uma indicação bastante certa de que a classe em questão está violando o Princípio de Responsabilidade Única, porque possui muitas dependências. Procure maneiras de refatorar essas dependências em agrupamentos de dependências de fachada .

Basta alterar sua estrutura de dados de parâmetro de a classpara structe você estará pronto.

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) 

O método agora terá sua própria cópia da estrutura. As alterações feitas na variável de argumento não podem ser observadas pelo método, e as alterações feitas pelo método na variável não podem ser observadas pelo chamador. O isolamento é alcançado sem imutabilidade.

Prós:

• Mais fácil de implementar
• Menos mudança de comportamento na mecânica subjacente

Contras:

• A imutabilidade não é óbvia, requer atenção do desenvolvedor.
• Cópia desnecessária para manter a imutabilidade
• Ocupa o espaço da pilha

Que tal criar uma classe de construtor dentro de sua classe de dados. A classe de dados terá todos os configuradores como privados e somente o construtor poderá configurá-los.

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

Eu não sou um programador de C #, mas acredito que o C # suporte argumentos nomeados: (o F # faz e o C # é amplamente compatível com esse tipo de coisa) Ele faz: http://msdn.microsoft.com/en-us/library/dd264739 .aspx # Y342

Assim, chamar seu código original se torna:

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

isso não ocupa mais espaço / pensamento de que o seu objeto é criado e possui todos os benefícios, do fato de você não ter alterado o que está acontecendo no sistema não-subjacente. Você nem precisa recodificar nada para indicar que os argumentos são nomeados

Edit: aqui está um artigo que eu encontrei sobre ele. http://www.globalnerdy.com/2009/03/12/default-and-named-parameters-in-c-40-sith-lord-in-training/ Eu devo mencionar que o C # 4.0 suporta argumentos nomeados, o 3.0 não

Por que não fazer apenas uma interface que imponha imutabilidade (ou seja, apenas getters)?

É essencialmente sua primeira solução, mas você força a função a usar a interface para acessar o parâmetro.

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

e a declaração da função se torna:

public ResultEnum DoSomeAction(IDoSomeActionParameters parameters, out Guid code)

Prós:

• Não tem problema de espaço na pilha como struct solução
• Solução natural usando semântica de linguagem
• Imutabilidade é óbvia
• Flexível (o consumidor pode usar uma classe diferente, se quiser)

Contras:

• Algum trabalho repetitivo (mesmas declarações em duas entidades diferentes)
• O desenvolvedor precisa adivinhar que DoSomeActionParametersé uma classe que pode ser mapeada paraIDoSomeActionParameters

Sei que essa é uma pergunta antiga, mas pensei em entrar na minha sugestão, pois tinha que resolver o mesmo problema. Agora, é certo que meu problema era um pouco diferente do seu, pois eu tinha o requisito adicional de não desejar que os usuários pudessem construir esse objeto eles mesmos (toda a hidratação dos dados veio do banco de dados, para que eu pudesse isolar toda a construção internamente). Isso me permitiu usar um construtor privado e o seguinte padrão;

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

Você pode usar uma abordagem no estilo Builder, embora, dependendo da complexidade do seu DoSomeActionmétodo, este possa ser um pouco pesado. Algo nesse sentido:

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

Além da resposta do manji - você também pode dividir uma operação em várias menores. Comparar:

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

e

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

Para quem não conhece o POSIX, a criação do filho pode ser tão fácil quanto:

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

Cada opção de design representa uma troca sobre quais operações ela pode realizar.

PS. Sim - é semelhante ao construtor - somente no sentido inverso (ou seja, no lado chamado em vez de no chamador). Pode ou não ser melhor do que o construtor nesse caso específico.

aqui está um pouco diferente de Mikeys, mas o que estou tentando fazer é tornar a coisa toda o mínimo possível para escrever

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

O DoSomeActionParameters é imutável como pode e não pode ser criado diretamente, pois seu construtor padrão é privado

O inicializador não é imutável, mas apenas um transporte

O uso tira proveito do inicializador no Inicializador (se você entender meu desvio). E eu posso ter padrões no construtor padrão do Inicializador.

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

Os parâmetros serão opcionais aqui, se você quiser que alguns sejam necessários, você pode colocá-los no construtor padrão Initializer

E a validação pode ir no método 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);
    }
}

Então agora parece

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

Ainda um pouco maluco, eu sei, mas vou tentar mesmo assim

Editar: mover o método create para uma estática no objeto de parâmetros e adicionar um delegado que passa no inicializador retira parte da chamada da chamada

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

Portanto, a ligação agora se parece com isso

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

Use a estrutura, mas em vez de campos públicos, tenha propriedades públicas:

• Todos (incluindo FXCop e Jon Skeet) concordam que a exposição de campos públicos é ruim.

Jon e FXCop ficarão satisfeitos porque você está expondo propriedades, não campos.

• Eric Lippert e colaboradores dizem que confiar em campos somente leitura para imutabilidade é uma mentira.

Eric ficará satisfeito porque, ao usar propriedades, você pode garantir que o valor seja definido apenas uma vez.

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

Um objeto semi-imutável (o valor pode ser definido, mas não alterado). Funciona para tipos de valor e referência.

Uma variante da resposta de Samuel que usei no meu projeto quando tive o mesmo problema:

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

E para usar:

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

No meu caso, os parâmetros foram intencionalmente modificáveis, porque os métodos setter não permitiram todas as combinações possíveis e apenas expuseram combinações comuns deles. Isso porque alguns dos meus parâmetros eram bastante complexos e os métodos de escrita para todos os casos possíveis teriam sido difíceis e desnecessários (combinações malucas raramente são usadas).