Applicazione del linguaggio di supporto per l'inizializzazione su richiesta a livello di variabili piuttosto che di classe

2

Stavo cercando il modo idiomatico per implementare l'inizializzazione pigra thread-safe per una collezione di configurazione recuperata dal DB all'interno di un bean Spring.

Ho deciso di adattare il modello di supporto per l'inizializzazione su richiesta come segue:

public class Security {

    private static ParametersDao DAO; 

    /**
     * Initialisation-on-demand Holder pattern
     */
    private static class StaticHolder {

        public static final Set<String> VALID_EMAIL_ADDRESSES;

        static {
            VALID_EMAIL_ADDRESSES = DAO.loadEmailAddresses();
        }
    }

    private ParametersDao parametersDao;

    public void setParametersDao(ParametersDao parametersDao) {
        this.parametersDao = parametersDao;
    }

    public Set<String> getValidEmails() {
        if (parametersDao == null) throw TooSoonException();
        DAO = parametersDao;
        return StaticHolder.VALID_EMAIL_ADDRESSES;
    }
}

Quali sono i problemi a cui prestare attenzione per adattare questo approccio in questo modo, a parte il problema di temporizzazione tra l'esigenza di utilizzare gli indirizzi email validi e l'inizializzazione del contenitore IoC?

    
posta Adam 17.12.2014 - 11:13
fonte

1 risposta

1

Memorizzando lo stato all'interno di una classe nidificata statica, ti stai limitando a essere in grado di istanziare una singola istanza di questo oggetto. Se è necessario utilizzare più implementazioni DAO o aggiungere un'altra dipendenza che deve essere modificata, ciò potrebbe causare un problema. Tali requisiti mi sembrano molto probabilmente al fine di testare sufficientemente questo codice.

Suggerirei semplicemente di utilizzare un metodo sincronizzato e allocare l'oggetto se il suo riferimento è nullo, a meno che tu non abbia una buona ragione per credere che il sovraccarico di questo approccio sarebbe troppo alto.

    
risposta data 17.12.2014 - 11:24
fonte