Se un metodo in classe A ha bisogno di una dipendenza extra ma non tutti i client lo usano, dovrei spostarlo da A?

Question

Se un metodo in classe A ha bisogno di una dipendenza extra ma non tutti i client lo usano, dovrei spostarlo da A?

#1 da (7 voti)
#2 da (3 voti)

6

Ad esempio, supponiamo di avere una classe del genere:

public class PlayerInfo{
    public loadDataFromDB(){
        //some code about DB framework
    }

    public string name;
    public int age;
    //other methods
    .
    .
    .
}

Ho trovato che molte classi utilizzano PlayerInfo, ma loadDataFromDB () viene chiamato solo all'avvio dell'applicazione. Mi sento a disagio perché ci sono così tante classi che dipendono dal framework di DB, ma non chiama mai loadDataFromDB (). Quindi la mia domanda è, dovrei separare il metodo loadDataFromDB () in una nuova classe:

public class PlayerInfoHelper{
    public static void loadDataFromDB(PlayerInfo playerInfo){
        //some code about DB framework
    }
}

in modo che ogni client di PlayInfo che non chiama loadDataFromDB () non dipenda dal framework DB?

object-oriented methods static-methods dependencies

posta mmmaaa 12.03.2018 - 04:50

fonte

2 risposte

3

Fai attenzione a cercare di definire regole rigide che ti attengono al 100% delle volte. La risposta è sempre "dipende".

Tuttavia, in questo caso penso che ci sarebbero dei vantaggi nella rimozione della dipendenza del database dalla tua classe PlayerInfo. Per prima cosa, impedirà a PlayerInfo di trasformarsi in un "oggetto dio". Rende anche molto più semplice fornire una strategia alternativa, non di database per caricare e salvare dati, che sarà preziosa se si desidera scrivere alcuni test unitari automatizzati per questa classe.

risposta data 12.03.2018 - 09:38

fonte

Leggi altre domande sui tag object-oriented methods static-methods dependencies

Come dovrebbero essere i parametri del metodo di servizio? Dobbiamo scrivere una funzione wrapper per pochi codici di linea?

score 7 · Accepted Answer

La risposta qui dipende da cosa stanno facendo i metodi stessi. Con un nome come loadDataFromDB() sembra che tu stia effettivamente caricando l'oggetto dal database. Se è così, dovresti farlo sicuramente altrove. Normalmente, le interazioni tra database coinvolgono la gestione delle transazioni, l'autenticazione di qualche tipo, l'apertura e la chiusura della connessione, la gestione del pool di thread, ecc. Anche se si sta utilizzando un ORM, continuerei a sostenere che la separazione delle preoccupazioni farebbe una distinzione tra il dominio di modellazione e l'accesso il tuo dominio da un archivio dati. Per esempio, stai potenzialmente accoppiando il tuo modello al negozio stesso. Cosa succede se si sta utilizzando una mappa in memoria thread sicura per lo sviluppo, ma si desidera utilizzare Postgres per la produzione? È un po 'improbabile, ma credetemi, i datastore cambiano spesso quando un'app deve scalare. La programmazione su un'interfaccia DAO consente di semplificare il codice chiamante e separare l'utente dallo specifico negozio.

Se d'altra parte, si assuma JDBC qui per il gusto di esempio, è necessario convertire un ResultSet in un POJO, quindi un costruttore nella classe del dominio che è del formato public PlayerInfo(ResultSet rs) , è perfettamente accettabile nel modello di dominio stesso.

In entrambi i casi, l'accesso ai dati non appartiene al modello di dominio stesso. Nel tuo caso, una sorta di classe DataProvider che carica tutti i modelli di dominio all'avvio ha più senso. Questa classe avrebbe un singolo punto di accesso che viene chiamato nel processo di avvio del server delle app. Questo punto di ingresso effettuerebbe quindi chiamate per caricare tutti i modelli di dati, tuttavia, se necessario,