Fluent interface

Kb. 2 éve olvastam először a fluent interface-ekről. Akkor nagyon megtetszett, és azóta is folyamatosan alkalmazom a módszert. Nem is gondoltam akkor, hogy Java-ban (vagy C#-ban) a legalapvetőbb nyelvi eszközökkel ilyen kifejező kódot lehet írni.

Az alapprobléma

Az eredeti probléma abban áll, hogy hogyan valósítsuk meg viszonylag sok paraméter átadását a kódban. A legalapvetőbb megoldás a standard módszer:

void doRegistration(String firstName, 

                    String lastName, 

                    String email, 

                    String password, 

                    String country, 

                    String city, 

                    String streetAddress1, 

                    String streetAddress2, 

                    String postalCode, 

                    boolean male, 

                    int age, 

                    boolean wantsNews) {

// ...

}

Jelen esetben 12 paraméter átadásáról van szó. Mondanom sem kell, hogy kínszevedés kliensként az ilyen metódust hívni, hiszen ahhoz, hogy tudjam, mit kell éppen átadni, az IDE-t kell segítségül hívnom. Ráadásul a keletkező kódot ilyen esetben borzasztó utólag is olvasni, hiszen nem rí le róla, hogy a híváskor milyen paraméterket, milyen sorrendben is adok át.

Martin Fowler Refactoring c. könyvében az Introduce Parameter Object c. minta próbál egyszerűsíteni a problémán, és azt javasolja, hogy rakjuk egy objektumba (osztályba) ezeket a paramétereket, majd ezt az objektumot adjuk át.

void doRegistration(RegistrationData data) {

// ...

}

Sajnos, a gond még mindig ugyanaz, hiszen magát a RegistrationData típusú objektumot is fel kell töltenünk ugyanezekkel a paraméterekkel. Megoldás lenne a setter-ek alkalmazása, de őszintén szólva, ha ilyet meglátok a kódban, egy kisebb agyvérzést kapok. Mivel mások által sem javasolt az objektumok kívülről történő piszkálása (sérti az egységbezárás elvét), célszerű más megoldást keresni, és itt jönnek a fluent interface-ek a képbe.

A megoldás

Kliens oldalon a következő a használandó kód (pl. egy tesztben):

RegistrationData registrationData = new RegistrationData()

    .withName("Béla", "Kovács")

    .withAccount("bela.kovacs@gmail.com", "pass1234")

    .withCountry("Hungary")

    .withCity("Budapest")

    .withAddress("Kossuth Lajos utca 13.", ""),

    .withPostalCode("1234"),

    .withMale(true)

    .withAge(20)

    .withWantsNews(false);

doRegistration(registrationData);

A RegistrationData osztály implementációja a következő:

public class RegistrationData {

    private String firstName;

    private String lastName;

    // további mezők

    RegistrationData() {

    }

    

    RegistrationData withName(String firstName, String lastName) {

        this.firstName = firstName;

        this.lastName = lastName;

        return this;

    }

    // további with-ek

    String getFirstName() {

        return firstName;

    }

    // további getter-ek (ha szükségesek egyáltalán)

}

A módszer előnye az, hogy amikor olvassuk a kódot, látszik, hogy a hívás pillanatában milyen paraméterek kapják a megfelelő értékeket. Ezért is kapta a fluent nevet a minta, hiszen folyamatosan, gondolkozás nélkül olvashatjuk a kódot, "folyékonyan", mintha természetes nyelven lenne írva. 

Látható az is, hogy nem muszáj egy az egyben átkonvertálni minden paramétert egy with... hívássá, azok csoportosíthatóak nagyobb, jól nevesíthető tömbökbe. Például a firstName-et és lastName-et együtt a withName... metódussal olvassuk be. (Viszont egy ilyen with... hívásba sem szabad sok paramétert bezsúfolni, mert akkor ugyanott tartunk, ahonnan elindultunk.)

A módszer egyetlen hátránya, hogy - a standard, sokparaméteres átadással szemben - nem kényszeríti ki az összes paraméter átadását. Az eredeti példa pl. nem fordul addig, amíg át nem adunk 12 akármilyen paramétert (a típusoknak azért egyezniük kell). Ezt azzal szokták orvosolni, hogy a paraméterek átadása után hívnak egy validate(), void visszatérési értékű metódust, amely elszáll, ha valamilyen paraméter nem lett kitöltve. Másik módszer a probléma megoldására, ha teszteket írunk. Amúgy - megsúgom - ha kihagyunk véletlenül egy paramétert, azt rövid időn belül úgyis észrevesszük, és korrigálhatunk, tehát nem célszerű emiatt túlságosan aggódni. Amit viszont cserébe kapunk, az a nagyfokú olvashatóság.