Come evitare il problema "troppi parametri" nella progettazione dell'API?

Ho questa funzione API:

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

Non mi piace Perché l'ordine dei parametri diventa inutilmente significativo. Diventa più difficile aggiungere nuovi campi. È più difficile vedere cosa succede. È più difficile refactoring del metodo in parti più piccole perché crea un altro sovraccarico di passaggio di tutti i parametri nelle funzioni secondarie. Il codice è più difficile da leggere.

Mi è venuta l'idea più ovvia: avere un oggetto che incapsula i dati e passarli invece di passare ogni parametro uno per uno. Ecco cosa mi è venuto in mente:

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

Ciò ha ridotto la mia dichiarazione API a:

public ResultEnum DoSomeAction(DoSomeActionParameters parameters, out Guid code)

Bello. Sembra molto innocente, ma in realtà abbiamo introdotto un enorme cambiamento: abbiamo introdotto la mutabilità. Perché quello che avevamo precedentemente fatto era in realtà passare un oggetto immutabile anonimo: parametri di funzione sullo stack. Ora abbiamo creato una nuova classe che è molto mutevole. Abbiamo creato la capacità di manipolare lo stato del chiamante . Che schifo Ora voglio il mio oggetto immutabile, cosa devo fare?

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

Come puoi vedere, ho ricreato il mio problema originale: troppi parametri. È ovvio che non è questa la strada da percorrere. Ciò che mi accingo a fare? L'ultima opzione per ottenere tale immutabilità è usare una struttura "di sola lettura" come questa:

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

Ciò ci consente di evitare costruttori con troppi parametri e raggiungere l'immutabilità. In realtà risolve tutti i problemi (ordinamento dei parametri ecc.). Ancora:

• Tutti (compresi FXCop e Jon Skeet) concordano sul fatto che esporre campi pubblici sia negativo .
• Eric Lippert e altri affermano che fare affidamento su campi di sola lettura per l'immutabilità è una bugia .

In quel momento mi sono confuso e ho deciso di scrivere questa domanda: qual è il modo più semplice in C # per evitare il problema "troppi parametri" senza introdurre la mutabilità? È possibile utilizzare una struttura di sola lettura a tale scopo e tuttavia non avere una cattiva progettazione API?

PRECISAZIONI:

• Si prega di supporre che non vi sia violazione del principio di responsabilità singola. Nel mio caso originale, la funzione scrive solo i parametri dati in un singolo record DB.
• Non sto cercando una soluzione specifica per la data funzione. Sto cercando un approccio generalizzato a tali problemi. Sono particolarmente interessato a risolvere il problema "troppi parametri" senza introdurre mutabilità o un design terribile.

AGGIORNARE

Le risposte fornite qui hanno diversi vantaggi / svantaggi. Pertanto, vorrei convertirlo in un wiki della comunità. Penso che ogni risposta con esempio di codice e pro / contro sarebbe una buona guida per problemi simili in futuro. Ora sto cercando di scoprire come farlo.

Uno stile abbracciato nei framework è di solito come raggruppare i parametri correlati in classi correlate (ma ancora una volta problematico con la mutabilità):

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

Utilizzare una combinazione di builder e API stile linguaggio specifico del dominio - Fluent Interface. L'API è un po 'più dettagliata ma con intellisense è molto veloce da scrivere e facile da capire.

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

Quello che hai è un'indicazione abbastanza sicura che la classe in questione stia violando il Principio di Responsabilità Singola perché ha troppe dipendenze. Cerca i modi per trasformare queste dipendenze in gruppi di dipendenze della facciata .

Basta cambiare la struttura dei dati dei parametri da a classa a structe sei a posto.

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) 

Il metodo ora otterrà la propria copia della struttura. Le modifiche apportate alla variabile argomento non possono essere osservate dal metodo e le modifiche apportate dal metodo alla variabile non possono essere osservate dal chiamante. L'isolamento si ottiene senza immutabilità.

Professionisti:

• Più facile da implementare
• Minimo cambio di comportamento nella meccanica di base

Contro:

• L'immutabilità non è ovvia, richiede l'attenzione degli sviluppatori.
• Copia non necessaria per mantenere l'immutabilità
• Occupa lo spazio dello stack

Che ne dici di creare una classe builder all'interno della tua classe di dati. La classe di dati avrà tutti i setter come privati ​​e solo il builder sarà in grado di impostarli.

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

Non sono un programmatore C # ma credo che C # supporti argomenti chiamati: (F # funziona e C # è ampiamente compatibile con le funzionalità per quel tipo di cose) Lo fa: http://msdn.microsoft.com/en-us/library/dd264739 aspx # Y342

Quindi chiamare il tuo codice originale diventa:

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

questo non richiede più spazio / pensiero che la creazione del tuo oggetto e ha tutti i vantaggi, del fatto che non hai affatto cambiato ciò che sta accadendo nel sistema immeriante. Non è nemmeno necessario ricodificare nulla per indicare che gli argomenti sono denominati

Modifica: ecco un articolo artistico che ho trovato al riguardo. http://www.globalnerdy.com/2009/03/12/default-and-named-parameters-in-c-40-sith-lord-in-training/ Dovrei menzionare che C # 4.0 supporta argomenti denominati, 3.0 no

Perché non creare semplicemente un'interfaccia che imponga l'immutabilità (cioè solo i getter)?

È essenzialmente la tua prima soluzione, ma imponi alla funzione di utilizzare l'interfaccia per accedere al parametro.

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 la dichiarazione di funzione diventa:

public ResultEnum DoSomeAction(IDoSomeActionParameters parameters, out Guid code)

Professionisti:

• Non ha problemi di spazio nello stack come structsoluzione
• Soluzione naturale usando la semantica del linguaggio
• L'immutabilità è ovvia
• Flessibile (il consumatore può utilizzare una classe diversa se lo desidera)

Contro:

• Alcuni lavori ripetitivi (stesse dichiarazioni in due entità diverse)
• Lo sviluppatore deve indovinare che DoSomeActionParametersè una classe a cui è possibile mappareIDoSomeActionParameters

So che questa è una vecchia domanda, ma ho pensato di essere d'accordo con il mio suggerimento dato che ho dovuto risolvere lo stesso problema. Ora, ammettevo che il mio problema era leggermente diverso dal tuo in quanto avevo il requisito aggiuntivo di non volere che gli utenti fossero in grado di costruire questo oggetto da soli (tutta l'idratazione dei dati proveniva dal database, quindi potevo imprigionare tutta la costruzione internamente). Questo mi ha permesso di usare un costruttore privato e il seguente schema;

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

Potresti usare un approccio in stile Builder, anche se a seconda della complessità del tuo DoSomeActionmetodo, questo potrebbe essere un tocco pesante. Qualcosa del genere:

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

Oltre alla risposta manji, potresti anche voler dividere un'operazione in più piccole. Confrontare:

 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[])
 ...

Per chi non conosce POSIX la creazione di un bambino può essere semplice come:

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

Ogni scelta di design rappresenta un compromesso rispetto alle operazioni che può svolgere.

PS. Sì - è simile al costruttore - solo al contrario (cioè sul lato chiamante anziché sul chiamante). In questo caso specifico potrebbe essere o meno meglio del costruttore.

qui è leggermente diverso da Mikeys, ma quello che sto cercando di fare è rendere tutto il meno possibile da scrivere

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 è immutabile in quanto può essere e non può essere creato direttamente poiché il suo costruttore predefinito è privato

L'inizializzatore non è immutabile, ma solo un trasporto

L'utilizzo sfrutta l'inizializzatore sull'inizializzatore (se ottieni la mia deriva) E posso avere i valori predefiniti nel costruttore predefinito dell'inizializzatore

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

I parametri saranno facoltativi qui, se vuoi che alcuni siano richiesti potresti metterli nel costruttore predefinito di Initializer

E la validazione potrebbe andare nel metodo 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);
    }
}

Quindi ora sembra

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

Conosco ancora un po 'di kooki, ma lo proverò comunque

Modifica: spostando il metodo di creazione su un oggetto statico nell'oggetto parametri e l'aggiunta di un delegato che passa l'inizializzatore elimina un po 'di kookieness dalla chiamata

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

Quindi la chiamata ora appare così

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

Utilizzare la struttura, ma invece dei campi pubblici, hanno proprietà pubbliche:

• Tutti (compresi FXCop e Jon Skeet) concordano sul fatto che esporre i campi pubblici sia negativo.

Jon e FXCop saranno soddisfatti perché stai esponendo proprietà non campi.

• Eric Lippert e altri affermano che fare affidamento su campi di sola lettura per l'immutabilità è una bugia.

Eric sarà soddisfatto perché usando le proprietà, puoi assicurarti che il valore sia impostato una sola volta.

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

Un oggetto semi-immutabile (il valore può essere impostato ma non modificato). Funziona con valori e tipi di riferimento.

Una variante della risposta di Samuel che ho usato nel mio progetto quando ho avuto lo stesso 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 usare:

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

Nel mio caso i parametri erano intenzionalmente modificabili, perché i metodi setter non consentivano tutte le possibili combinazioni, ma ne esponevano semplicemente combinazioni comuni. Questo perché alcuni dei miei parametri erano piuttosto complessi e la scrittura di metodi per tutti i possibili casi sarebbe stata difficile e superflua (le combinazioni folli sono usate raramente).