Android Studio - kiedy (nie)używać wyrażeń lambda?

Jak w temacie.
Jak jest z tym używaniem lambd w Android Studio ( nie tylko dla interfejsów jak na tym przykładzie, ale ogólnie, kiedy tak, kiedy nie).
Czy wpychacie je praktycznie wszędzie w definiowaniu pojedyńczych interfejsów, czy może wolicie nie używać i widzieć całą definicję w kodzie dla łatwiejszego połapania się co tam jest?

Dla przykładu, snapshot dla obiektu Google Maps.

        GoogleMap.SnapshotReadyCallback callback1 = new GoogleMap.SnapshotReadyCallback() {
            @Override
            public void onSnapshotReady(Bitmap snapshot) {
                try {
                   // capture screenshot
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        };
        
        GoogleMap.SnapshotReadyCallback callback2 = (snapshot) -> {
            try {
              // capture screenshot
            } catch (Exception e) {
                e.printStackTrace();
            }
        };

O ile w przypadkach typowych zastosowań jak dla onClick(), od razu wiadomo co kryje się pod wyrażeniem lambda, o tyle dla jakichś bardziej nietypowych interfejsów ( chociażby pisanych od zera przez nas) trzeba "wiedzieć" co tam jest. Nie jest to jakoś problematyczne, ale chciałem sobie zaimplementować trochę tych wyrażeń w projekcie (zacznę od tego rodzaju definicji interfejsów) i nie chcę przegiąć w drugą stronę, że wepchnę je wszędzie, nawet tam gdzie nie powinno ich być.
W tym momencie szukam/czytam sobie o nich, ale może ktoś będzie miał coś ciekawego do powiedzenia i tutaj.

Używając lambdy można chyba zawsze zapisać czytelne znaczeniowo wyrażenie. Jeśli sensownie nazwiesz metodę, gdzie lambdę przekazujesz jako argument, albo wyciągniesz ją do zmiennej, którą dobrze nazwiesz, to osoba czytająca kod nie powinna mieć problemu z jego zrozumieniem. Raczej będzie nawet czytelniej, bo nie trzeba będzie zwracać uwagi na nadmiarowe informacje (np. "onSnapshotReady" i "SnapshotReadyCallback"). Użycie lambdy może nie mieć sensu gdy chcesz umieścić w niej dłuższy kod, podzielić go na metody. Wtedy, jeśli umieszczenie tych metod w klasie definiującej lambdę nie miałoby sensu, musiałbyś użyć klasy anonimowej, albo nawet utworzyć nową klasę.

Czyli jak ze wszystkim: stosować ze zdrowym rozsądkiem.

Naszło mnie na powyższe przemyślenia, gdy Android Studio zasugerowało mi, żebym zastosował lambdę w JavaRx:

    Observable<List<XmlAirportValues>> getNearestAirportsObservable(final Uri airportUri, final String parserMode) {
        return Observable.defer(new Func0<Observable<List<XmlAirportValues>>>() {
            @Override
            public Observable<List<XmlAirportValues>> call() {
                return Observable.just(getNearestAirports(airportUri, parserMode));
            }
        });
    }

I sugerowana wersja:

    Observable<List<XmlAirportValues>> getNearestAirportsObservable(final Uri airportUri, final String parserMode) {
        return Observable.defer(() -> Observable.just(getNearestAirports(airportUri, parserMode)));
    }

Nie jestem jeszcze na tym poziomie, żeby było to dla mnie lepsze, ale może przyjdzie na to czas.¯_(ツ)_/¯