Le migliori pratiche da evitare "Giocare al telefono" con argomenti del costruttore

Per espandere il commento di @ 9000, utilizzerei oggetti che forniscono maggiori informazioni e possibilmente un controllo degli errori sui tuoi argomenti. Ad esempio, nel seguito:

drawLine(100, 20, 300, 30);
drawLine(new Point(100, 20), new Point(300, 30));

Il secondo è generalmente più leggibile. Può controllare gli errori (le coordinate possono essere negative? Un rettangolo può avere una larghezza o un'altezza negativa?) E fornisce un modo più semplice per accedere ai metodi di supporto (come la conversione di sistemi di coordinate o trasformazioni affini). Inoltre, se viene passato un sacco di dati (come un elenco di punti per una polilinea), si finisce per passare i riferimenti agli oggetti piuttosto che l'intera struttura dei dati.

Non sono del tutto sicuro di come sia la tua gerarchia di classi, ma ti darò le mie idee sulla costruzione degli oggetti e su come ho iniziato a progettare le mie lezioni nei progetti su cui lavoro.

• Ereditarietà o composizione: sembra che tu stia partendo dal presupposto che, poiché stai programmando in uno stile OO, devi sempre usare l'ereditarietà; questo non è vero Spetta a te, il progettista, determinare quale soluzione risolva meglio il tuo problema. Di seguito ti fornirò un esempio di composizione anziché di ereditarietà.

• Oggetti parametro (come lo metti): quando si progetta un corso, si modellano i dati in base a come vengono visualizzati nella propria testa; gli stai dando un nome e una struttura. Un semplice esempio sarebbe una classe chiamata Point2D che avrebbe una proprietà X ed una associata a quella classe. La cosa buona della creazione di questo "oggetto parametro" è ora che puoi creare funzioni o metodi che operano su quell'oggetto. Non creo Point2D con un costruttore, creo una seconda classe chiamata Point2DFactory con un metodo statico Create (x, y). Questo fa 2 cose per me, mantiene il mio peso leggero classe Point2D e mette tutta la logica per creare un Point2D in un unico posto. Ora posso comporre un Point2D in qualsiasi modo lo desidero e Point2D non è più responsabile sia di essere un punto sia di sapere come viene creato un punto. Non è legato a una catena ereditaria, è compito di Point2DFactory preoccuparsi di ciò.

• Inversion of Control: se hai bisogno di incapsulare alcune funzionalità di overarching in un singolo oggetto che può essere scomposto in piccole parti di funzionalità, puoi usare un'inversione del framework di controllo per aiutarti. Quello che fa è prendere tutti quegli "oggetti parametro" che hai creato (si spera con interfacce astratte) e capire come costruire l'oggetto che ti interessa iniettando la funzionalità nel suo costruttore.

Se stai creando costruttori che si basano su alcuni calcoli matematici per generare i loro parametri, prendi in considerazione la creazione di un oggetto parametro e una fabbrica che lo crea. Quindi puoi creare un'altra fabbrica che crei l'oggetto desiderato in base a qualsiasi input desideri. Puoi dire che uso molto lo schema di fabbrica: P? Spero che ciò che ho detto ti mostri che creare più oggetti non è una cosa negativa (OOP lo richiede: /) e se puoi ottenere che ogni classe / oggetto abbia una sola responsabilità, il tuo codice base generale sarà estremamente flessibile e piacere da mantenere.

MODIFICA in risposta al commento: Forse non sto capendo esattamente cosa stai chiedendo. Ho pensato al tuo problema quali costruttori nidificati hanno nomi di input simili. Quello che stavo cercando di ottenere è che, in generale, un genitore non dovrebbe aver bisogno di sapere come istanziare i suoi oggetti figli. Ciò rende i tuoi genitori responsabili di fare ciò che è sempre il genitore fa AND per creare gli oggetti figli. Se lo scopo dell'anima del genitore è creare gli oggetti figli, ciò è chiamato fabbrica nei termini del modello di progettazione. Invece del concatenamento del costruttore, trascina quella logica che crea un'istanza di oggetti secondari all'esterno dei costruttori. Ciò ti offre una più flessibile fruibilità della logica che crea oggetti figlio e una migliore aderenza ai principi SOLID.