Wildcardok

A wildcardok rugalmasabb generikus API-t adnak, ha típuscsaládok között kell együttműködni.

1. Definíció

A wildcard a generics egyik eszköze arra, hogy ne egyetlen konkrét típusparaméterhez ragaszkodj, hanem egy típuscsaládot fogadj el. Interjún tipikusan azt kérdezik, hogy mikor használj <?>, <? extends T> vagy <? super T> formát. Ez a téma ott fontos, ahol producer-consumer szemlélet, PECS elv és kollekciók közötti együttműködés jelenik meg. A lényeg nem a jelölés bemagolása, hanem annak megértése, hogy mit lehet biztonságosan olvasni vagy írni.

2. Alapfogalmak

Fogalom	Jelentés	Miért fontos
<?>	Ismeretlen típusú lista	Olvasni lehet Object-ként, írni gyakorlatilag nem.
<? extends Number>	Felső korlátos wildcard	Olvasásra jó, mert minden elem legalább Number.
<? super Integer>	Alsó korlátos wildcard	Írásra jó Integer típusú értékekkel.
PECS	Producer Extends, Consumer Super	Gyors döntési szabály wildcard választáshoz.
Invariance	A List<Integer> nem List<Number>	Ezért kell wildcard a rugalmassághoz.

• A generikus típusok invariánsak: attól, hogy Integer leszármazottja a Number-nek, még a List<Integer> nem lesz List<Number>.
• A <? extends T> akkor jó, ha főleg olvasol a struktúrából; biztonságosan tudod T-ként kezelni az elemeket.
• A <? super T> akkor jó, ha főleg írsz bele; T és annak altípusai biztonságosan betehetők.
• Az unbounded wildcard <?> akkor praktikus, ha a konkrét típus nem fontos, csak a kollekció mint absztrakció.

3. Gyakorlati használat

A(z) Wildcardok témában a legfontosabb gyakorlati kérdés mindig az, hogy milyen use-case-re választasz eszközt. A jó interjúválasz itt nem csak azt mondja meg, mit lehet csinálni, hanem azt is, mikor érdemes és mikor nem.

• Használj <? extends T>-t olyan metódusparaméterhez, ami adatforrásként viselkedik, például másoló vagy összegző metódusban.
• Használj <? super T>-t olyan célkollekciónál, ahová T értékeket teszel.
• Ha csak a méret, iteráció vagy logolás érdekel, akkor Collection<?> általában jobb, mint a nyers típus.
• Interjún érdemes kimondani: wildcard inkább API-határon jellemző, osztályszintű tárolt mezőként ritkábban ideális.

4. Kód példák

Egyszerű példa

import java.util.List;

public class WildcardRead {
    public static double sum(List<? extends Number> numbers) {
        double total = 0;
        for (Number number : numbers) {
            total += number.doubleValue();
        }
        return total;
    }
}

Haladó példa

import java.util.ArrayList;
import java.util.List;

public class WildcardCopy {
    public static <T> void copy(List<? extends T> source, List<? super T> target) {
        for (T item : source) {
            target.add(item);
        }
    }

    public static void main(String[] args) {
        List<Integer> source = List.of(1, 2, 3);
        List<Number> target = new ArrayList<>();
        copy(source, target);
        System.out.println(target);
    }
}

A kódpéldák interjún azért hasznosak, mert megmutatják, hogy a fogalmi szintű tudást le tudod fordítani konkrét API-használatra. Ha röviden el tudod magyarázni, miért így írod a példát, az általában többet ér, mint egy túlbonyolított demo.

5. Trade-offok

Szempont	Előny	Hátrány
Wildcardos API	Rugalmasabb metódusszignatúra	Nehezebb elsőre olvasni
extends	Biztonságos olvasás felső korláttal	Nem tudsz általánosan írni bele
super	Biztonságos írás consumer szerepben	Olvasáskor csak Object-et kapsz vissza biztosan

6. Gyakori hibák

• ❌ Rossz: List<Integer>-t próbálsz átadni List<Number> paraméternek. ✅ Helyes: Használj wildcardot, például List<? extends Number>.
• ❌ Rossz: List<? extends Number>-be elemeket akarsz add-olni. ✅ Helyes: Olvasásra használd, íráshoz válassz ? super-t vagy konkrét típust.
• ❌ Rossz: Wildcardot tárolsz mezőként ott is, ahol a konkrét típus ismert. ✅ Helyes: API-határon wildcard, domain modellen belül inkább konkrét vagy típusparaméterezett típus.

7. Senior szintű meglátások

Senior szinten a wildcardokat nem izolált szabályként, hanem API ergonomia szempontjából értékeljük. A kérdés az, hogy a hívó mennyire kényelmesen tudja használni a metódust.

Gyakori follow-up: miért nem jó mindenhová ? extends Object? Mert nem ad valódi többletet, viszont félreviszi az olvasót és korlátozhatja az írást.

PECS jó emlékeztető, de nem helyettesíti a gondolkodást. Mindig azt nézd, hogy a paraméter producerként vagy consumerként viselkedik-e.

Tipikus follow-up interjúkérdések:

• Hogyan magyaráznád el röviden a(z) Wildcardok témát egy junior fejlesztőnek?
• Milyen trade-offot látsz a(z) Wildcardok kapcsán valós projektben?
• Milyen tipikus production hibát tudsz ehhez a témához kötni?

8. Szószedet

Kifejezés	Jelentés
wildcard	Ismeretlen típushelyettesítő, például ?.
upper bound	Felső korlát, pl. ? extends Number.
lower bound	Alsó korlát, pl. ? super Integer.
PECS	Producer Extends, Consumer Super.
invariance	A generikus típusok nem kovariánsak alapból.

9. Gyorsreferencia

• <?> = ismeretlen típus, főleg olvasás/meta műveletek.
• <? extends T> = producer, olvasáshoz.
• <? super T> = consumer, íráshoz.
• List<Integer> nem List<Number>.
• PECS = gyors döntési szabály.

Ha interjún elakadsz, a(z) Wildcardok témánál mindig térj vissza a három alapelvhez: pontos definíció, tipikus use-case, és a legfontosabb trade-off vagy hiba.