Dando a una classe molti costruttori e assegnando loro più proprietà possibili

Mi scusi mentre reagisco a tutti suggerendo il modello del costruttore qui:

Questo è C #, non Java!

Un motivo principale per il modello di builder di Joshua Bloch consiste nell'incidere su Java mancanza di argomenti nominati. Ciò fornisce a Java un modo per aggirare il malvagio modello di costruzione telescopico .

Sei in C #. Hai nominato argomenti!

Un altro motivo per il modello di builder di Joshua Bloch consiste nel separare gli argomenti richiesti da argomenti opzionali (quelli che hanno un buon valore di default) e permettono di impostare qualsiasi combinazione di argomenti opzionali. Questo è necessario perché Java non supporta in modo nativo argomenti facoltativi.

Sei in C #. Hai argomenti facoltativi!

Ciò significa che i 3 costruttori che hai elencato dovrebbero essere sostituiti con solo 1:

public SQLiteTrigger(
    string Name, 
    string On, 
    TriggerStartType StartType, 
    TriggerEventType EventType, 
    string TriggerSQL = "some default string", 
    string When = "some other default string"
)

E ora, a differenza di prima, i clienti possono cambiare When senza giocherellare con TriggerSQL .

new SQLiteTrigger(
    Name: "MyTrigger", 
    On: "Whatever", 
    StartType: new TriggerStartType(),
    EventType: new TriggerEventType(),
    When: "Now"
)

Rispetto al costruttore Bloch questo è

• Più facile per i client (umani) da utilizzare
• Più facile da implementare
• Un design flessibile

Non fraintendermi, adoro il costruttore Bloch. In Java. Non utilizzare soluzioni alternative agli hacker in lingue che non ne hanno bisogno.

Ora hai chiesto informazioni sul buon stile e hai menzionato l'aggiunta di ulteriori parametri. Fai attenzione ad aggiungere a molti. Questo è chiamato arity . Troppo arbit è un odore di codice che può indicare un difetto nella progettazione sottostante. Ci sono modi per ridisegnare a ridurre l'arie .

Se questi parametri aggiuntivi sono più complicati del semplice richiesto rispetto a opzionale (con un predefinito noto) , potresti essere interessato al prossimo passo oltre il Costruttore Bloch. Il builder DSL .

Is it against any design rules or considered as bad practice when you give a class many constructors and assign via them as many properties as possible?

Questo suona come:

1. hai bisogno di un modello di build . Implementa un builder e puoi chiamare ripetutamente 'build ()' su un builder costruito in precedenza, regolare i parametri come richiesto
2. se hai così tante proprietà, la tua classe ha bisogno di scomporre in più classi, ognuna con una specifica responsabilità ben definita? Se la tua classe ha così molte proprietà, inizierei a chiedermi se sta facendo troppo da solo

Is it against any design rules or considered as bad practice when you give a class many constructors and assign via them as many properties as possible?

Non penso che sia una cattiva pratica farlo, ma penso che la vera domanda qui sia: sei sicuro che siano davvero necessari? C'è il principio dello sviluppo del software YAGNI (che non ne hai bisogno) che potrebbe applicarsi qui nel tuo caso, devi solo fare ciò di cui hai veramente bisogno e smettere di pensare che questo o quello potrebbe essere utile in futuro.

Ti invito a leggere questo piccolo articolo che ho scritto qualche tempo fa che potrebbe aiutarti un po 'a prendere la decisione da solo: KISS, YAGNI & ASCIUTTO, 3 principi per semplificare la vita come sviluppatore