Paresseux champ d'initialisation avec des lambdas

Au sein de votre effectif lambda, vous pouvez simplement mettre à jour le fooField avec une nouvelle lambda, tels que:

class A<T>{
    private Supplier<T> fooField = () -> {
       T val = expensiveInit();
       fooField = () -> val;
       return val;
    };

    public T getFoo(){
       return fooField.get();
    }
}

À nouveau cette solution n'est pas thread-safe, comme c'est le .Net Lazy<T>, et de ne pas s'assurer que les appels simultanés à la getFoo propriété retournent le même résultat.

L'approche adoptée par Miguel Gamboa réponse est un parfait:

private Supplier<T> fooField = () -> {
   T val = expensiveInit();
   fooField = () -> val;
   return val;
};

Il fonctionne bien pour une paresseuse champs. Cependant, si plus d'un champ doit être initialisé de cette façon, le standard devra être copié et modifié. Un autre domaine devront être initialisé comme ceci:

private Supplier<T> barField = () -> {
   T val = expensiveInitBar();          //<< changed
   barField = () -> val;                //<< changed
   return val;
};

Si vous avez un appel de méthode par l'accès après l'initialisation, je le ferais comme suit. Tout d'abord, je voudrais écrire une fonction d'ordre supérieur qui renvoie une instance de Fournisseur qui contient la valeur mise en cache:

static <Z> Supplier<Z> lazily(Supplier<Z> supplier) {
    return new Supplier<Z>() {
        Z value; //= null
        @Override public Z get() {
            if (value == null)
                value = supplier.get();
            return value;
        }
    };
}

Une classe anonyme est ici parce qu'il a mutable état, qui est la mise en cache de la initialisée valeur.

Ensuite, il devient assez facile de créer de nombreux initialisées champs:

Supplier<Baz> fieldBaz = lazily(() -> expensiveInitBaz());
Supplier<Goo> fieldGoo = lazily(() -> expensiveInitGoo());
Supplier<Eep> fieldEep = lazily(() -> expensiveInitEep());

Remarque: je vois dans la question qu'il prévoit que "sans l'aide d'un if". Il n'était pas clair pour moi si le souci ici est sur le souci d'éviter le runtime cher d'un si-conditionnel (vraiment, c'est assez bon marché) ou si c'est plus sur la façon d'éviter d'avoir à répéter la si-à condition que dans tous les getter. J'ai supposé que c'était le dernier, et ma proposition répond à cette préoccupation. Si vous êtes inquiet au sujet de gestion d'exécution d'un si (conditionnel, alors vous devriez également prendre la surcharge de l'invocation d'une expression lambda en compte.

Il est pris en charge,

Par la création d'une petite interface et la combinaison de 2 nouvelles fonctionnalités introduites dans java 8:

• @FunctionalInterface annotation (permet d'assigner un lambda sur la déclaration)
• default mot-clé (définir une mise en œuvre, tout comme la classe abstraite -, mais dans une interface)

Il est possible d'obtenir la même Lazy<T> comportement comme vous l'avez vu en C#.

---

Utilisation

Lazy<String> name = () -> "Java 8";
System.out.println(name.get());

Lazy.java (copiez et collez cette interface en quelque part accessible)

import java.util.function.Supplier;

@FunctionalInterface
public interface Lazy<T> extends Supplier<T> {
    abstract class Cache {
        private volatile static Map<Integer, Object> instances = new HashMap<>();

        private static synchronized Object getInstance(int instanceId, Supplier<Object> create) {

            Object instance = instances.get(instanceId);
            if (instance == null) {
                synchronized (Cache.class) {
                    instance = instances.get(instanceId);
                    if (instance == null) {
                        instance = create.get();
                        instances.put(instanceId, instance);
                    }
                }
            }
            return instance;
        }
    }

    @Override
    default T get() {
        return (T) Cache.getInstance(this.hashCode(), () -> init());
    }

    T init();
}

---

En Ligne Exemple - https://ideone.com/3b9alx

L'extrait de code suivant illustre le cycle de vie de cette classe d'assistance

static Lazy<String> name1 = () -> { 
    System.out.println("lazy init 1"); 
    return "name 1";
};

static Lazy<String> name2 = () -> { 
    System.out.println("lazy init 2"); 
    return "name 2";
};

public static void main (String[] args) throws java.lang.Exception
{
    System.out.println("start"); 
    System.out.println(name1.get());
    System.out.println(name1.get());
    System.out.println(name2.get());
    System.out.println(name2.get());
    System.out.println("end"); 
}

sortie

start
lazy init 1
name 1
name 1
lazy init 2
name 2
name 2
end

---

Voir la démo en ligne - https://ideone.com/3b9alx

Vous pourriez faire quelque chose le long de ces lignes :

   private Supplier heavy = () -> createAndCacheHeavy();

   public Heavy getHeavy()
   {
      return heavy.get();
   }

   private synchronized Heavy createAndCacheHeavy()
   {
      class HeavyFactory implements Supplier
      {
         private final Heavy heavyInstance = new Heavy();

         public Heavy get()
         {
            return heavyInstance;
         }
      }

      if(!HeavyFactory.class.isInstance(heavy))
      {
         heavy = new HeavyFactory();
      }

      return heavy.get();
   }

J'ai récemment vu cela comme une idée par Venkat Subramaniam. J'ai copié le code de cette page.

L'idée de base est que le Fournisseur une fois appelé, remplace lui-même avec une simple usine de mise en œuvre qui renvoie l'instance initialisée.

C'était dans le contexte de thread-safe initialisation d'un singleton, mais vous pouvez également l'appliquer à un champ normal, évidemment.

Si vous besoin de quelque chose qui se rapproche le comportement de Lazy en C#, qui vous donne la sécurité des threads, et une garantie que vous obtenez toujours la même valeur, il n'y a pas de façon simple d'éviter if.

Vous aurez besoin d'utiliser un champ volatile et une double vérification de verrouillage. Ici est la plus faible empreinte mémoire version d'une classe qui vous donne le C# comportement:

public abstract class Lazy<T> implements Supplier<T> {
    private enum Empty {Uninitialized}

    private volatile Object value = Empty.Uninitialized;

    protected abstract T init();

    @Override
    public T get() {
        if (value == Empty.Uninitialized) {
            synchronized (this) {
                if (value == Empty.Uninitialized) {
                    value = init();
                }
            }
        }
        return (T) value;
    }

}

Il n'est pas élégant à utiliser. Vous devez créer paresseux valeurs comme ceci:

final Supplier<Baz> someBaz = new Lazy<Baz>() {
    protected Baz init(){
        return expensiveInit();
    }
}

Vous pouvez acquérir une certaine élégance à le coût supplémentaire de la mémoire, par l'ajout d'une usine de méthode comme ceci:

    public static <V> Lazy<V> lazy(Supplier<V> supplier) {
        return new Lazy<V>() {
            @Override
            protected V init() {
                return supplier.get();
            }
        };
    }

Maintenant, vous pouvez créer de thread safe paresseux valeurs tout simplement comme ceci:

final Supplier<Foo> lazyFoo = lazy(() -> fooInit());
final Supplier<Bar> lazyBar = lazy(() -> barInit());
final Supplier<Baz> lazyBaz = lazy(() -> bazInit());

Comment à ce sujet.
Certains J8 fonctionnelle switcheroos pour éviter fi sur chaque accès.
Avertissement: pas de thread courant.

import java.util.function.Supplier;

public class Lazy<T> {
    private T obj;
    private Supplier<T> creator;
    private Supplier<T> fieldAccessor = () -> obj;
    private Supplier<T> initialGetter = () -> {
        obj = creator.get();
        creator = null;
        initialGetter = null;
        getter = fieldAccessor;
        return obj;
    };
    private Supplier<T> getter = initialGetter;

    public Lazy(Supplier<T> creator) {
        this.creator = creator;
    }

    public T get() {
        return getter.get();
    }

}

2 solutions, l'une fonctionnelle d'alors et d'un objet (c'est même code), thread-safe, sans "si", et en prenant soin de gestion d'Exception avec le bon type de propagation (pas de solution ici, prendre soin à ce sujet).

Elle est assez courte. Mieux paresseux champs de soutien, géré par le runtime, finira par rendre ce code obsolète...

utilisation :

final Lazy<Integer, RuntimeException> lazyObject = new LazyField<>(() -> 1);

final Lazy<Integer, RuntimeException> finalFunc = lazyField(() -> value(1)); //less efficient than object

private Lazy<Integer, IOException> lazyFunc = lazyField(() -> this.lazyFunc = value(1)); //more efficient than object

private static Lazy<Integer, AnyException> lazyTest = lazyField(() -> {throw new AnyException();});

J'ai d'abord définir un lambda exception :

@FunctionalInterface
interface SupplierWithException<T, E extends Exception> {
    T get() throws E;
}

Puis un Paresseux type :

interface Lazy<T, E extends Exception> extends SupplierWithException<T, E> {}

Version fonctionnelle :

Il renvoie directement un lambda qui finit par avoir le moins de mémoire, si ce n'est pas sur un champ final comme dans l'exemple ci-dessus.

static <T, E extends Exception> Lazy<T, E> lazyField(Lazy<Lazy<T, E>, E> value) {
    Objects.requireNonNull(value);
    Lazy<T, E>[] field = new Lazy[1];
    return () -> {
        if(field[0] == null) {
            synchronized(field) {
                if(field[0] == null) {
                    field[0] = value.get();
                }
            }
        }
        return field[0].get();
    };
}

static <T, E extends Exception> Lazy<T, E> value(T value) {
    return () -> value;
}

On ne peut pas appliquer de donner une valeur correcte de rappel, au moins, il retourne toujours le même résultat, mais ne peut éviter le "si" (comme dans final sur le terrain).

Version d'objet :

Est entièrement protégé de l'extérieur.

public final class LazyField<T, E extends Exception> implements Lazy<T, E> {

    private Lazy<T, E> value;

    public LazyField(SupplierWithException<T, E> supplier) {
        value = lazyField(() -> value = value(supplier.get()));
    }

    @Override
    public T get() throws E {
        return value.get();
    }
}

profiter de