Interfejsy funkcyjne - korzystać gdzie się da?

Ostatnio zaprzyjaźniłem się z wbudowanymi w Jave interfejsami funkcyjnymi i dosyć szybko zacząłem korzystać tam gdzie to możliwe z method reference zamiast klasycznych metod. Zacząłem się jednak zastanawiać:

1. czy to dobry nawyk?
2. czy robię to dobrze?

Przykład takiej klasy poniżej.

Przy okazji, ostatnio oglądałem tutorial i w konstruktorze ze springowym Autowired za każdym razem używano oprócz standardowej inicjalizacji pól klasy również metody super() pomimo, że nie było tam żadnego dziedziczenia. Czy to ma coś na celu?

@Service
public class MatcherDomesticIndex {

    private LoaderDomesticIndex loaderDomesticIndex;
    private LoaderPublicCompanyNewConnect loaderPublicCompanyNewConnect;
    private LoaderPublicCompanyMainMarket loaderPublicCompanyMainMarket;
    private List<PublicCompany> allCompanies;

    @Autowired
    public MatcherDomesticIndex(LoaderDomesticIndex loaderDomesticIndex, LoaderPublicCompanyNewConnect loaderPublicCompanyNewConnect,
                                LoaderPublicCompanyMainMarket loaderPublicCompanyMainMarket) {
        this.loaderDomesticIndex = loaderDomesticIndex;
        this.loaderPublicCompanyNewConnect = loaderPublicCompanyNewConnect;
        this.loaderPublicCompanyMainMarket = loaderPublicCompanyMainMarket;
    }

    private void addAllCompanies() {
        allCompanies = new ArrayList<>();
        allCompanies.addAll(loaderPublicCompanyNewConnect.getLoadedAssets().stream().map(e -> (PublicCompany) e).collect(Collectors.toList()));
        allCompanies.addAll(loaderPublicCompanyMainMarket.getLoadedAssets().stream().map(e -> (PublicCompany) e).collect(Collectors.toList()));
    }

    private Function<PublicCompany, Pair<PublicCompany, Optional<PublicCompany>>> pairSingleCompany =
            a -> new Pair<>(a, Optional.ofNullable(allCompanies.stream().filter(e -> e.getName().equals(a.getName()))
                    .findFirst().orElse(null)));

    private Function<List<PublicCompany>, List<Pair<PublicCompany, Optional<PublicCompany>>>> pairListOfCompanies = e -> e.stream()
            .map(pairSingleCompany).collect(Collectors.toList());

    private Function<List<Pair<PublicCompany, Optional<PublicCompany>>>, List<PublicCompany>> convertToPublicCompanyListWithoutNulls =
            l -> l.stream().filter(e -> e.getR().isPresent()).map(p -> p.getR().get()).collect(Collectors.toList());

    private Function<List<PublicCompany>, List<PublicCompany>> pairCompanies = pairListOfCompanies.andThen(convertToPublicCompanyListWithoutNulls);

    private Consumer<DomesticStockIndex> matchSingleIndex = i -> i.setCompanies(pairCompanies.apply(i.getCompanies()));

    private Consumer<List<DomesticStockIndex>> matchAllIndexes = i -> i.forEach(matchSingleIndex);

    private BiConsumer<DomesticStockIndex, PublicCompany> addIndexToCompany = (i, c) -> c.getDomesticStockIndexes().add(i);

    private Consumer<DomesticStockIndex> addIndexToAllCompanies = i -> i.getCompanies().forEach(c -> addIndexToCompany.accept(i, c));

    public void matchIndexesWithCompanies() {
        addAllCompanies();
        matchAllIndexes.accept(loaderDomesticIndex.getLoadedAssets().stream()
                .map(e -> (DomesticStockIndex) e).peek(addIndexToAllCompanies).collect(Collectors.toList()));
    }
}

Wow, patrzyłem na to kilka minut i nic nie rozumiem. Więc to jest albo genialne albo idiotyczne.

Jak dla mnie, w twoim przypadku to zupełnie niepotrzebnie zaciemnia kod, mi jest bardzo ciężko się w tym odnaleźć. Co chcesz uzyskać używając, zamiast metody, pola z instancją Function<A, B>, która to instancja i tak będzie zawierać kod metody w środku?

Tylko i wyłącznie kwestia wygody. Przyjemnie mi się tak pisze. Jednak po kilku takich klasach doszedłem do wniosku, że po napisaniu to może być nieczytelne zwłaszcza jeżeli ktoś z doskoku na to spojrzy i póki co moje obawy zdają się potwierdzać. :)

Jest to bardzo nieczytelne i brzydkie. Daje mocne 2/10

Zawsze kiedy coś stosujesz odpowiedz sobie na pytanie, co to daje (ew. jaki jest trade-off) ;)

Kiedyś (Java <=7) jak się używało FluentIterable z Guavy z klasami anonimowymi to miało to sens, aby poszczególne transformacje extractować i nazywać. Tutaj nie widzę sensu.

Czyli generalnie się z interfejsów funkcyjnych w taki sposób nie korzysta czy raczej nie w takiej ilości? Czyli 1 implementacja OK, ale więcej już niekoniecznie ze względu na nieczytelność?

Jak jesteś młody to:
Marnujesz się w javie - idź do haskella, F#, albo przynajmniej Scali.

Życie jest za krótkie, żeby rypać się z taką składnią.

olfeusz napisał(a):

1. czy to dobry nawyk?

Zależy kogo spytać:

• W Javie jest to herezja - bo generuje dużo nadmiarowego kodu
• W Haskellu i Scheme - świętość (tam składnia definicji funkcji prawie niczym się nie różni od składni definicji lambdy z przypisaniem od razu do zmiennej)
• W Scali i Kotlinie jest różnie, zależy kogo spytasz

@KamilAdam: Jak to "nadmiarowy kod"? Ja rozumiem, że kod Javy czasem jest jak spaghetti, ale napisaną klasę częściej się używa niż edytuje.

Osobiście korzystam z interfejsów funkcyjnych jedynie w Stream API, sam nie tworzę metod które przyjmują / zwracają taki interfejs.

Kopiuj

   private Function<PublicCompany, Pair<PublicCompany, Optional<PublicCompany>>> pairSingleCompany =
           a -> new Pair<>(a, Optional.ofNullable(allCompanies.stream().filter(e -> e.getName().equals(a.getName()))
                   .findFirst().orElse(null)));

   private Function<List<PublicCompany>, List<Pair<PublicCompany, Optional<PublicCompany>>>> pairListOfCompanies = e -> e.stream()
           .map(pairSingleCompany).collect(Collectors.toList());

   private Function<List<Pair<PublicCompany, Optional<PublicCompany>>>, List<PublicCompany>> convertToPublicCompanyListWithoutNulls =
           l -> l.stream().filter(e -> e.getR().isPresent()).map(p -> p.getR().get()).collect(Collectors.toList());

No generalnie nawet ma to sens, pod warunkiem że lubisz wbijać gwoździe tłuczkiem do mięsa i jednocześnie ściskając łebek w ręce...

Pierwsze co, to te typy palą w oczy. List<Pair<PublicCompany, Optional<PublicCompany>>> aż krzyczy żeby to w coś opakować, tego się zwyczajnie czytać nie da. Pozbądź się tego i od razu będzie czytelniej.

A odnosząc się do pytań:

1. używanie method reference w ogólności jest spoko, ale nie musisz definiować jakichś pól z lambdami żeby móc się do nich odnosić. Do zwykłej metody też się da, i to bez eksponowania typu-krzaka, mniej więcej tak:

interface Pub { // interfejsy bo czemu nie, nawet nie musisz znać implementacji
    Address getAddress()
}

/* bla bla bla */

interface Town {
    List<Pub> findPubs()
}

/* bla bla bla */

List<Address> addresses = town.findPubs()
    .stream()
    .map(Pub::getAddress)
    .collect(Collectors.toList())

1. No nie wiem, te deklaracje-krzaki po prostu straszą. No i nawet nie mogę się doszukać jakiegoś użycia tych polo-lambd. Jak dla mnie taki górotwór w Javie miałby jakikolwiek sens tylko w przypadku, gdyby te lambdy były dostarczane z zewnątrz (i nie byłoby ich pięćset, bo kto by chciał składać obiekt ze srylionem lambd do przekazania). A że nie są, tylko definiujesz je na sztywno w klasie, to nie mają sensu.

Jeśli bardzo chcesz tak robić to posłuchaj rad Jarka i i idź do języka, który nie będzie Cię karał upierdliwą składnią za pisanie w ten sposób ;)

PerlMonk napisał(a):

@KamilAdam: Jak to "nadmiarowy kod"? Ja rozumiem, że kod Javy czasem jest jak spaghetti, ale napisaną klasę częściej się używa niż edytuje.

Jeśli dokładasz nowe funkcjonalności to może tylko dokładasz nowy kod. Ja pracuję w projektach gdzie cały czas zmieniają funkcjonalności i cały czas trzeba zmieniać stary kod. I cały czas trzeba czytać stary kod. Im go mniej tym łatwiej się go czyta