Uso dei validatori per semplici convalide

Question

Uso dei validatori per semplici convalide

#1 da (1 voti)

2

Ho lavorato con il codice Liferay e ho trovato questo costrutto alcune volte:

List<?> list;
...
if (Validator.isNotNull(list)) {
    //do stuff
}}

Il codice sorgente per Validator.java assomiglia a questo:

public static boolean isNotNull(Object obj) {
    return !isNull(obj);
}

public static boolean isNull(String obj) {
    ...
}

public static boolean isNull(Long obj) {
    ...
}

public static boolean isNull(Integer obj) {
    ...
}

public static boolean isNull(Object obj) {
    if (obj instanceof String) {
        return isNull((String)obj);
    }

    if (obj instanceof Long) {
        return isNull((Long)obj);
    }

    if (obj instanceof Integer) {
        return isNull((Integer)obj);
    }

    return obj == null;
}

Quindi la mia domanda: quali sono i vantaggi di chiamare Validator a svolgere questa funzione anziché scrivere semplicemente if (obj == null) ? Queste chiamate di funzione aggiungono un sovraccarico abbastanza significativo che vale la pena evitare questo metodo di programmazione?

java validation java-ee

posta patstuart 12.03.2015 - 00:06

fonte

1 risposta

Leggi altre domande sui tag java validation java-ee

Qual è il miglior design del repository? Gestione degli eventi in linea Javascript rispetto a gestori di eventi jQuery esterni

score 1 · Answer 1

Guarda l'implementazione di isNull per diversi tipi. Ad esempio string :

public static boolean isNull(String s) {
    if (s == null) {
        return true;
    }

    s = s.trim();

    if ((s.length() == 0) || (s.equals(StringPool.NULL))) {
        return true;
    }

    return false;
}

Questo non è lo stesso di obj == null , perché se obj ha un valore di "\ t", il confronto nullo restituirà false . D'altra parte, isNull restituirà true a causa del s = s.trim() seguito da s.length() == 0 .

Se hai utilizzato .NET Framework, isNull(String s) è ciò che viene chiamato string.IsNullOrWhiteSpace() : un nome molto migliore per il metodo.

Ad esempio, nel tuo primo pezzo di codice, se list è un elenco vuoto, non nullo:

list == null restituirà false ,
Validator.isNull(list) restituirà true .

Do these function calls add a significant enough overhead that it is worth avoiding this method of programming?

Poiché il metodo non fa la stessa cosa di obj == null , confrontare le sue prestazioni non ha senso. Il chiamante di isNull usa questo metodo perché è comodo quando si cerca, per esempio, una lista vuota o vuota o una stringa vuota, vuota o di spazi bianchi.

Ovviamente, se l'unica cosa che ti serve è controllare se la variabile è nullo, fai solo obj == null ; Validator.isNull non è per questo (nonostante il suo nome).

Si noti che il sovraccarico di isNull(Object) fa un ulteriore lavoro di confronto tra il tipo di oggetto e infine il cast. Ciò significa che quando si utilizza la libreria di validatori, si dovrebbe cercare di lavorare sempre con le variabili digitate. Ad esempio:

Object obj = this.loadSomethingFromProxy();
if (Validator.isNotNull(obj))
{
    something = (Long)obj;
    this.doStuff(something);
}

dovrebbe essere refactored in:

Long something = (Long)this.loadSomethingFromProxy();
if (Validator.isNotNull(obj))
{
    this.doStuff(something);
}

perché nel caso successivo, stai facendo il cast una sola volta (invece di due volte) e poi chiama il sovraccarico isNotNull(Long) , saltando il controllo del tipo.