Dal punto di vista di OOP, tenendo conto delle prestazioni - una connessione di database dovrebbe essere un campo statico, un campo istanza o una variabile locale?

In generale, quando le connessioni database utilizzate sono variabili locali, poiché vengono quasi sempre recuperate da una fabbrica per semplificare l'astrazione dei dettagli di implementazione. Pragmaticamente , quei dettagli contano visto che quasi sempre vuoi mettere in comune le connessioni del tuo database, e la fabbrica gestisce tutto ciò.

La factory a sua volta di solito è una variabile di istanza poiché spesso si desidera la flessibilità di utilizzare istanze diverse laddove necessario.

In primo luogo, facciamo una dichiarazione chiara sulle prestazioni: nel 99,99% di tutti i casi reali le prestazioni saranno letteralmente le stesse, quindi - come al solito - le prestazioni non sono un criterio utile per prendere una decisione del genere.

Le domande principali che dovresti porci qui sono:

• "posso immaginare una situazione in cui ho bisogno di connessioni di database diverse per funzioni diverse nella mia classe" (o anche per la stessa funzione all'interno dello stesso oggetto, quando viene chiamato in un contesto multithreading, ad esempio)?

• "devo aspettarmi un bisogno di connessioni di database differenti per oggetti diversi", oppure devo supporre che non ci sia sempre un "contesto globale" disponibile dove potrebbe essere disponibile la "connessione globale db" ( per esempio, in una situazione di test)?

• "Sono sicuro al 100% che tutto il mio programma / libreria si connetterà sempre a un solo database, e non ci sarà mai bisogno di usare una connessione / database diversi allo stesso tempo?"

Se la risposta alla prima domanda è "sì", è chiaro che hai bisogno della connessione come parametro per le tue funzioni. Se la risposta al primo è "no", ma al secondo è "sì", si dovrebbero campi di istanza. E se la risposta alla terza domanda è "sì", puoi utilizzare una "variabile globale" (o un campo statico), probabilmente evitando un codice di tipo standard.

Quindi tutto si riduce a "non esiste l'unica soluzione migliore". Dipende dal tipo di programma che stai scrivendo, è un'applicazione che usa sempre un db o molti, è una libreria che potrebbe potenzialmente utilizzare nuovamente database diversi allo stesso tempo, e così via. Quindi la soluzione "migliore" è quella che soddisfa meglio le tue esigenze.

Una classe di configurazione è probabilmente la migliore in quanto sarà DRY e implementerà un'interfaccia (lo mantiene testabile). L'interfaccia deve avere un metodo che accetta stringhe SQL e restituisce un oggetto.

Diverse implementazioni possono essere fatte per ambienti diversi.

Risposta breve: dal punto di vista di OOP questo dovrebbe essere un dettaglio di implementazione.

È possibile nascondere questo dettaglio di implementazione se si dispone di un metodo di istanza che viene utilizzato come variabile del metodo locale. In questo modo le tue tre opzioni sono dettagli di implementazione che possono essere facilmente modificati in qualsiasi momento con poche righe di codice:

class MyService {
    protected DBConnection getDBConnection() {
        return new DBConnection(...); // version 3: local variable in method
    }
    protected void closeDBConnection(DBConnection con) {
        con.close(); // version 3: local variable in method
    }

    doSomething() {
        protected DBConnection con = getDBConnection();
        ...
        closeDBConnection(con);     
    }
}

La modifica dei dettagli di implementazione alla versione 1 o 2 richiede solo di modificare getDBConnection () e closeDBConnection () senza influire sui servicemets doSomething1 (), doSomething2 (), ...

la versione statica diventerebbe

class MyService {
    private static DBConnection sConnection = null;
    protected DBConnection getDBConnection() {
        if (sConnection == null) sConnection = new DBConnection(...);
        return sConnection;
    }
    protected void closeDBConnection(DBConnection con) {
        // do nothing
    }
 }

Il modello di progettazione per questo è chiamato "Metodo di fabbrica".