dati facoltativi nel costruttore, cattiva pratica?

I parametri facoltativi non sono una cattiva pratica, sicuramente no, ma a volte i parametri facoltativi possono essere facoltativi solo a causa di ciò che fa la classe.

Sei arrivato a un problema che è il risultato di un cattivo design. Stai cercando di capire come ignorare certe proprietà di un modello se non le usi. Il problema è che state mescolando le responsabilità delle classi insieme e provate a creare una classe che conosce e fa molte cose. Questo è abbastanza brutto e potrebbe causare problemi in seguito, perché sarà molto difficile riutilizzare la classe in un ambiente diverso, per esempio.

Ovviamente, quando hai una classe che può fare molte operazioni, ci sarà una situazione in cui un'operazione non avrà bisogno di tutto ciò che la classe contiene, ma è necessaria per altre operazioni.

Ciò che dovresti fare è dividere la tua classe attuale in diverse classi più piccole, ciascuna responsabile di una sola cosa e fare in modo che la classe faccia la cosa giusta. Potresti avere un UserModel, che potrebbe essere una rappresentazione reale di un utente nel tuo codice, potresti quindi avere un qualche tipo di servizio, che accetterebbe l'utente e fare un'operazione su di esso. Ovviamente, se l'operazione richiede l'accesso al database, è necessario fornire una classe che funge da accessore del database alla classe di servizio come dipendenza.

Personalmente, opterei per il refactoring della classe monolitica in molti più piccoli, ognuno dei quali prende solo la dipendenza (o le dipendenze) di cui ha realmente bisogno.

L'uso di costruttori di parametri facoltativi elimina la necessità di sovraccarichi di più costruttori.

In Java, c'è un intero pattern software per questo chiamato Builder Pattern, che sostanzialmente sostituisce più costruttori con un'interfaccia fluente. È un modello elaborato, eccessivamente complesso e in definitiva insoddisfacente; i parametri facoltativi del costruttore sono una soluzione molto migliore.

Sì e No. Dipende.

Scenario 1: sei l'unico sviluppatore del progetto o il tuo progetto personale.

Le pratiche non contano . Ciò che conta è che funzioni e sia di buona qualità.

Scenario 2: ci sono molte persone che lavorano su questo progetto

Sì, è una cattiva pratica . Solo i campi obbligatori devono far parte dei parametri del costruttore. O utilizzare i costruttori sovraccaricati o abbattere la classe in più. Ricorda anche che il codice noioso che il team comprende è meglio di un codice intelligente che solo una persona comprende.