2015-07-13 13 views
15

Sono assegnato a un lavoro di ottimizzazione delle prestazioni di un'applicazione.Il passaggio di un oggetto a un metodo può aumentare le prestazioni rispetto all'invio di singoli parametri

Spesso è necessario passare 16-25 parametri al costruttore e impostarli lì. Voglio creare un oggetto classe & per questo e impostare questi valori sull'oggetto e quindi passare. Sarà buono da leggere. Ma farà del mio meglio (l'ottimizzazione delle prestazioni)?

+18

di passaggio che molti parametri di un costruttore è un odore di codice comunque prescindere prestazione. Con tutti questi parametri, è molto probabile che si verifichi un errore (ad esempio, l'inversione di due parametri dello stesso tipo). –

+0

http://stackoverflow.com/questions/5727336/performance-of-variable-argument-methods-in-java, che dovrebbe aiutarti. –

+1

Suggerirei di profilare vari aspetti della vostra applicazione per identificare dove sono effettivamente i colli di bottiglia prima di tentare di ottimizzare. Ad esempio, qualsiasi cosa riguardi l'accesso alla rete, le query del database scritte male, ecc. – Romski

risposta

15

Potrebbe migliorare leggermente le prestazioni, ma il vantaggio principale sarebbe aumentare la leggibilità del codice. Un costruttore con 16-25 parametri non è leggibile e molto difficile da usare.

Naturalmente, è necessario introdurre solo nuove classi che abbiano senso (ovvero i parametri sono correlati tra loro). Non ha senso spostare 15-26 parametri non correlati in una classe solo per il fatto di passarli a un costruttore.

+7

Perché pensi che migliorerebbe le prestazioni? Non stai creando un oggetto in più? – Keppil

+2

@Keppil potresti essere in grado di creare quell'oggetto una sola volta e usarlo in molti posti. –

+1

@Keppil Bene, copiare un riferimento anziché 15-26 in ogni chiamata al costruttore può fare una piccola differenza. Quindi, anche l'istanziazione del nuovo oggetto richiederebbe del tempo. Ecco perché ho scritto "potrebbe". Se si sta creando una nuova istanza una volta e riutilizzandola in molte chiamate all'altra funzione di costruzione, si potrebbe ottenere un piccolo miglioramento. – Eran

14

Le differenze di prestazione che derivano da questo, se ce ne sono, sono molto improbabili da notare.

Se il tuo compito è risolvere i problemi di prestazioni, il tuo primo compito è individuare dove si trovano i problemi. Lo fai profilando l'applicazione. Lo hai fatto e ha dimostrato che il problema è nel passaggio dei parametri?

5

Sarebbe piuttosto inusuale nel software moderno avere 25 variabili libere su una funzione di chiamata, e quindi passarle esplicitamente a un metodo o un ctor.

Nella maggior parte dei casi, in una progettazione OO, queste variabili sarebbero invece già inserite in una classe (o in alcune classi), raggruppate in base alle loro responsabilità logiche.

E dal momento che Java passa oggetti per riferimento, il passaggio di un riferimento a un singolo oggetto sullo stack potrebbe avere alcuni vantaggi in termini di prestazioni (un numero inferiore di variabili da inviare allo stack). Tuttavia il vero vantaggio sarebbe la leggibilità e la manutenzione del codice.

Occorre tuttavia notare che fare ciò richiederebbe che la classe dell'oggetto che viene passato sia condivisa tra consumatore e servizio: questo potrebbe essere un problema, a seconda di cosa la classe di trasferimento sta modellando (ad esempio, è un trasferimento di dati Oggetto, entità aziendale, modello di vista, oggetto di serializzazione XML/JSON, ecc.). Se il tipo di condivisione tra caller e callee violerebbe la tua architettura, allora tipicamente mapperai le 25 variabili in un'altra classe canonica (o classi, ancora osservando i problemi di refactoring SRP) e passerai invece a questi (questi). A questo punto, non ci saranno benefici per le prestazioni, ma il vantaggio di leggibilità/manutenibilità verrà mantenuto.

0

Come oops suggeriscono collaborare più proprietà in una singola unità denominata classe, che è rappresentato da un oggetto in modo che possa migliorare le prestazioni e la prontezza di codice