Collections.emptyList () au lieu de la vérification null?

Si j'ai rarement utilisée collection dans une classe qui peut être instancié plusieurs fois, j'ai peut parfois recourir à la suite de "l'idiome" afin d'économiser de l'inutile créations objet:

List<Object> list = null;

void add(Object object) {
    if (list == null)
        list = new ArrayList<Object>();

    list.add(object);
}

//somewhere else
if (list != null)
    for (Object object : list)
         ;

Maintenant, je me demandais si je ne pouvais pas éliminer ceux null vérifie à l'aide de Collections.emptyList()cependant alors que j'aurais à modifier la si vérifier dans add() comme suit:

if (list == Collections.<Object>emptyList())
    list = new ArrayList<Object>();

Est-il une meilleure façon de gérer cela autres que la simple attribution d'un nouveau regroupement vide à chaque fois?

EDIT: juste pour être clair, je voudrais utiliser des Collections.emptyList(), mais la vérification ci-dessus dans la méthode add() est vraiment vraiment moche... je me demandais si il ya une meilleure façon de le faire ou même d'une tout autre façon de gérer cela.

source d'informationauteur Philip Kamenarsky

  1. 16

    afin d'économiser de l'inutile créations objet

    Qui est une très mauvaise idée qui fera la litière de votre code avec == null contrôles et la manipulation de cas de coin (et sans doute à la fin dans son pointeur null exceptions tout de même)!

    Maintenant, je me demandais si je ne pouvais pas éliminer ceux null vérifie à l'aide de Collections.emptyList()

    Non, pas vraiment. emptyList() retourne une liste vide. Vous pourrait ne 

    if (list.equals(Collections.<Object>emptyList()))

    mais qui va encore jeter un NullPointerException si list == nullil est donc toujours pas ce que vous êtes après.

    Ma recommandation: Toujours initialiser la liste de new ArrayList<Object>ou, si par exemple vous voulez renvoyer une liste vide à partir d'une méthode, l'utilisation Collections.emptyList() à la place. (Ceci renvoie à la même instance à chaque fois, donc pas inutile de création d'objet non plus.)

    Et ensuite utiliser .isEmpty() pour vérifier si la collection est vide ou pas.

  2. 7

    Les réponses proposées sont absolument correct, juste un petit conseil en Java 8, vous pouvez utiliser la nouvelle Classe optionnelle pour gérer le cas où l'instance de liste est nul, dans une approche plus fonctionnelle.

    Par exemple, quelque chose comme ceci:

    public static List<String> addElement(List<String> list, String toAdd) {
       List<String> newList = Optional.ofNullable(list).orElse(new ArrayList<>());
       newList.add(toAdd);
       return newList;
}
  3. 1

    emptyList() ne pas affecter un objet à chaque fois.

    Je voudrais créer moins de l'objet qui contient la Liste de sorte que vous pouvez créer la liste à chaque fois.

    Ce que vous pouvez faire est de

    private List<Object> list = Collections.emptyList();

private List<Object> listForWrite() {
    return list.isEmpty() ? list = new ArrayList<Object>() : list;
}


void add(Object object) {
    listForWrite().add(object);
}


//avoid creating an Iterator every time.
for (int i = 0, size = list.size(); i < size; i++) {
     ;
}
  4. 1

    Voici ce que j'utilise une méthode d'aide dans certains de mon code. Fonctionne vraiment bien dans la réduction de la tonne de nulle vérifie que j'avais normalement lieu avant l'itération sur les listes. Si vous voulez une liste qui ne soit pas immuable ensuite, vous pouvez revenir une nouvelle liste d'objet à la place de Collections.emptyList

    /**
 * Helper method to return an empty list if provided one is null.
 *
 * @param list the list
 * @return the provided list or an empty one if it was null
 */
private static <T> List<T> emptyIfNull(List<T> list) {
    if (list == null) {
        return Collections.emptyList();
    }
    return list;
}

    Vous utilisez la méthode d'assistance comme suit:

    for (Object object : emptyIfNull(existingList)) { ... }

    Si la liste d'objet est null, alors la méthode d'assistance sera le retour de la statique de la liste vide et le contenu de votre boucle sera ignorée. C'est une belle façon pour éviter d'avoir à créer de la valeur null vérifie enveloppant toute la liste des itérations.

    J'ai fait de l'intérieur de la liste d'Objet de type juste pour l'exemple, mais vous feriez bien évidemment modifier à tout ce qui fait le plus de sens pour votre utilisation.

  5. 0

    Si vous utilisez uniquement la liste pour les itérations, vous pouvez simplement utiliser: for (Object object : list) qui ne serait pas faire n'importe quoi pour vider les listes, c'est à dire pas une seule itération.

    Sinon, il suffit de vérifier list.isEmpty().

  6. 0

    Vous pouvez créer une classe utilitaire avec des méthodes statiques, comme:

    public class ListUtil {

/**
 * Checks if {@link List} is null or empty.
 *
 * @param <E> the generic type
 * @param list the list
 * @return true, if is null or empty
 */
public static <E> boolean isNullOrEmpty(List<E> list) {
    return list == null || list.size() == 0;
}

/**
 * Checks if {@link List} is not null and empty.
 *
 * @param <E> the generic type
 * @param list the list
 * @return true, if is not null and empty
 */
public static <E> boolean isNotNullAndEmpty(List<E> list) {
    return list != null && list.size() != 0;
}

    }

  7. 0

    Je trouve qu'il est plus facile de suivre cette convention:

    1. Si le point de ma méthode est de renvoyer une Collection, la méthode ne retourne null. La valeur Null est ambigu. Au lieu de cela je retour Collection.emptyXXX() ou ImmutableXXX.of() si à l'aide de la Goyave.

    2. Si j'ai un objet qui est le maintien d'une liste interne en tant que membre, l'instancier dans le constructeur. J'essaie de ne pas paresseux instanciation, sauf si on peut prouver son un gain significatif en raison paresseux code, à mon avisa tendance à être plus difficile à déboguer lorsque des problèmes surviennent.

    Je vois vraiment immuable ou inmodifiable vide collections étant une partie d'un contrat externe à des objets. Si vous utilisez la collecte en interne, je ne peux vraiment voir à l'aide de immuable collections, si vous avez une bonne raison (de la simultanéité, de la cohérence, de l'immutabilité de l'objet)