Set di parametri di coppia

Question

Set di parametri di coppia

#1 da (4 voti)
#2 da (3 voti)
#3 da (2 voti)

4

Ho la seguente classe, questa classe come molti si basa su un parametro che entra in coppia. Originariamente per comodità, li ho impostati come params Object[] values e controllo se ne esiste un numero pari if (values % 2 == 0) .

Codice di esempio:

using RVD = System.Web.Routing.RouteValueDictionary;

/// <summary>
/// Allows for quick building of similar RVDs.
/// </summary>
public class RVDBuilder
{
    public RVD Template { get; protected set; }

    public RVDBuilder(RVD template)
    {
        this.Template = template;
    }
    public RVDBuilder(params Object[] routeValues)
    {
        if (routeValues.Length % 2 != 0)
        {
            throw new Exception("parameters must come in pairs of two!");
        }
    }
}

Posso vedere due punti di vista qui:

Questo aggiunge grande convenienza per il programmatore: cioè new RVDBuilder("Key1", 1, "Key2", "2", ...);
Questo non è sicuro come potrebbe essere: cioè new RVDBuilder(Tuple.Create("Key1", 1), ...);

Speravo di ricevere informazioni su questo argomento / argomento.

Dovrei forzare il programmatore ad usare una classe 'coppia'? (Come influirebbe sull'accoppiamento?)
Dovrei renderlo più sicuro anche se sarà una soluzione facile da prendere in caso di errore?
Il lancio di un'eccezione è il modo migliore per gestirlo o devo solo troncare?
Aggiungendo un evento in modo che il programmatore possa scegliere come gestire la situazione è una buona pratica?

Nel complesso però, come posso identificare e decidere un metodo per gestire questa situazione? So che in generale dipende dall'impostazione del progetto, ma su questo argomento non c'è un vero mood / convention. Ci sono delle regole generali?

(Scusa se questo non è il giusto StackExchange per questa domanda. Riguarda il codice, ma ho pensato che è puramente ad esempio per aiutare a spiegare meglio la mia domanda di progettazione che si adatta meglio qui).

object-oriented design coupling parameters

posta Shelby115 27.02.2015 - 18:17

fonte

3 risposte

3

Ho letto in "Effective C ++" che le API dovrebbero essere sempre facili da usare correttamente e difficili da usare in modo errato. Dal momento che hai affermato che può essere utilizzato in modo errato, lo abbandonerei per una soluzione che può essere più sicura.

risposta data 27.02.2015 - 18:33

fonte

2

La tua classe si chiama RVDBuilder . Il punto del modello di builder è quello di evitare costruttori ridicolmente complessi e consentire invece di raccogliere gradualmente tutte le informazioni necessarie tramite normali chiamate di metodo. Pertanto, la soluzione migliore sarebbe quella di aggiungere un'interfaccia fluente per aggiungere coppie di informazioni:

class RVDBuilder {
  public RVDBuilder Add(string key, Object value) { … }
  public RVD Instantiate() { … }
}

Then: new RVDBuilder().Add("foo", 42).Add("bar", "baz").Instantiate() .

risposta data 28.02.2015 - 09:48

fonte

Leggi altre domande sui tag object-oriented design coupling parameters

Lambda è ancora supportata in Python? Una convenzione newline non fa parte di una codifica?

score 4 · Accepted Answer

Ho dovuto affrontarlo di recente in Java. La mia soluzione era di rendere la classe Pair abbastanza semplice da istanziare: Pair.of(..., ...) . Questo è solo 7 caratteri extra prima delle parentesi, e il naming del metodo factory of sembra essere una convenzione che le classi basate sul valore seguono in Java 8.

Ma nel mio caso d'uso non c'erano in genere più di 3-4 coppie, quindi ho anche fornito sovraccarichi per un massimo di 5 coppie di argomenti, quindi le tuple devono essere usate raramente. È una formula irragionevole da scrivere, ma deve essere eseguita solo una volta e i chiamanti ne beneficiano molte volte.

Should I force the programmer to use a 'pair' class? (How would this affect coupling?)

Una classe "coppia" è una dipendenza abbastanza innocua. Ha una piccola interfaccia e una semantica ben definite e un'implementazione semplice e diretta. È molto improbabile che la sua interfaccia cambierà o che qualcuno la romperà in futuro. È anche molto improbabile che dipenda da altre classi.

Is throwing an exception the best way to handle it or should I just truncate?

Non non tronca. Questo è chiaramente un errore nella parte del programmatore, e non si può nemmeno presumere che il valore mancante sia alla fine: una volta ho accidentalmente fuso due stringhe attorno al centro dell'elenco degli argomenti, ad es. "foo", "bar", "baz", "quux" diventato "foo", "bar baz", "quux" . Non c'è niente da fare per te se non annullare un'eccezione.

Would adding an event so the programmer can choose how to handle the situation be good practice?

Non c'è motivo per il programmatore di passare deliberatamente in una lista di argomenti non validi, quindi se l'errore viene gestito, probabilmente si verificherà a un gestore di errori "catch all" di livello elevato, non alla chiamata del metodo. Il chiamante può già rilevare l'eccezione se lo desidera, quindi l'evento non sarà di aiuto.