2009-02-10 11 views
19

Stavo pensando a quanto codice si dovrebbe inserire nei costruttori in Java? Voglio dire, molto spesso si fanno metodi di aiuto, che si invocano in un costruttore, ma a volte ci sono alcune cose di inizializzazione più lunghe, ad esempio per un programma, che legge da un file, o interfacce utente, o altri programmi, in cui non si 'Inizializza solo le variabili di istanza, in cui il costruttore può allungarsi (se non si utilizzano metodi di supporto). Ho in mente qualcosa che i costruttori dovrebbero generalmente essere brevi e concisi, non dovrebbero? Ci sono eccezioni a questo?Quanto codice si deve inserire in un costruttore?

+0

prova questo articolo, dovrebbe rispondere alla tua domanda: http://www.yegor256.com/2015/05/07/ctors-must-be-code-free.html – yegor256

risposta

10

Se si seguono i principi SOLID, ogni classe dovrebbe avere una ragione per cambiare (ad esempio, fare una cosa). Di conseguenza, un costruttore normalmente non sta leggendo un file, ma avresti una classe separata che crea gli oggetti dal file.

+0

grazie, mi hai solo aiutato a evitare di rompere l'SRP! –

2

Appena necessario per completare l'inizializzazione dell'oggetto.

Se si può parlare di una porzione (circa 5 linee è la mia linea guida) del costruttore come una porzione di logica o di un processo specifico, è probabilmente meglio dividerlo in un metodo separato per chiarezza e scopi organizzativi.

Ma a ciascuno il suo.

1

Costruttori dovrebbe essere abbastanza a lungo, ma non è più =)

Se si definisce più sovraccaricato costruttori, non duplicare il codice; invece, consolidare le funzionalità in una di esse per maggiore chiarezza e facilità di manutenzione.

+0

Ehi, è una buona pratica aggiungere accessor nei costruttori? –

1

Come ha detto Knuth, "l'ottimizzazione prematura è la radice di tutti i mali".

Quanto dovresti mettere in cassa? Tutto il necessario. Questo è l'approccio "desideroso". Quando - e solo quando - le prestazioni diventano un problema, consideri di ottimizzarlo (con approcci "pigri" o "eccessivi").

+0

Le prestazioni non sono di solito il problema; la manutenzione è! Non sono sicuro di evitare un'ottimizzazione prematura significa evitare un'ottimizzazione prematura della manutenzione ... – skiphoppy

+0

Sì, non penso che questo problema riguardi le prestazioni ... si tratta piuttosto di progettare un codice corretto che sia manutenibile e facile da comprendere per gli altri. –

+0

Sì e il modo migliore per scrivere codice gestibile è scriverlo in modo semplice (cioè desideroso). Il caching per le prestazioni tende a complicare la codifica della realtà, il che è controproducente se le prestazioni non sono un problema. – cletus

4

Dai uno sguardo allo this SO question. Anche se l'altro è per C++, i concetti sono ancora molto simili.

1

I costruttori devono creare l'istanza generica minima del proprio oggetto. Quanto generico? Scegli i casi di test che ogni istanza o oggetto che eredita dalla classe deve passare per essere valido - anche se "valido" significa solo fallire con garbo (eccezione generata dal programma).

Wikipedia ha una buona descrizione:

http://en.wikipedia.org/wiki/Constructor_(computer_science)

un oggetto valido è l'obiettivo del costruttore, non è valida necessariamente utile - che può essere fatto in un metodo di inizializzazione.

0

La mia prassi corrente è che se tutto ciò che il costruttore deve fare è impostare alcuni campi su un oggetto, può essere arbitrariamente lungo. Se diventa troppo lungo, significa che il design della classe è rotto in ogni caso, o che i dati devono essere impacchettati in strutture più complesse.

Se, d'altra parte, i dati di input richiedono una elaborazione più complessa prima di inizializzare i campi di classe, tendo a fornire al costruttore i dati elaborati e spostare l'elaborazione su un metodo di produzione statico.

0

È possibile che la classe debba essere inizializzata in un determinato stato, prima che qualsiasi lavoro utile possa essere eseguito con esso.

Considerate questo.

public class CustomerRecord 
{ 
    private Date dateOfBirth; 

    public CustomerRecord() 
    { 
     dateOfBirth = new Date(); 
    } 

    public int getYearOfBirth() 
    { 
     Calendar calendar = Calendar.getInstance(); 
     calendar.setTime(dateOfBirth); 
     return calendar.get(Calendar.YEAR); 
    } 
} 

Ora, se non si inizializza il varialble membro dateOfBirth, ogni successiva invocazione di getYearOfBirth(), si tradurrà in un NullPointerException.

Quindi l'inizializzazione minimo che può comportare

  1. Assegnazione di valori.
  2. Richiamo delle funzioni di supporto.

per garantire che la classe si comporti correttamente quando i membri vengono invocati in seguito, è tutto ciò che deve essere fatto.

0

Constructor è come un Setup Wizard Application dove si fa solo configurazione. Se l'istanza è pronta a prendere qualsiasi (possibile) Azione su se stessa, quindi il Costruttore sta facendo bene.

Problemi correlati