Iterable gir deg for-each-løkka

Grensesnittet Iterable<T> har én metode, Iterator<T> iterator(). Når en klasse implementerer det, kan man skrive for (T x : objekt) direkte på objektet i stedet for å hente ut en intern liste først. Det er akkurat dette eksamen spør om når den skriver «hva betyr dette for koden en kan skrive for å gå gjennom barna til en Person?».

Det enkleste svaret er å delegere til den interne samlingen sin iterator:

public class Kortstokk implements Iterable<Kort> {
    private final List<Kort> kort = new ArrayList<>();

    @Override
    public Iterator<Kort> iterator() {
        return kort.iterator();      // delegerer
    }
}

// gir: for (Kort k : kortstokk) { ... }

Merk innkapslingskonsekvensen: kort.iterator() har en remove()-metode, så den som får iteratoren kan fjerne elementer. Vil du hindre det, returner Collections.unmodifiableList(kort).iterator().

Egen Iterator-klasse

Når du skal iterere over noe som ikke allerede er en samling — for eksempel bare verdiene til de terningene som ikke er låst — må du skrive iteratoren selv. Kontrakten er enkel: hasNext() sier om det er mer igjen, og next() gir neste element og flytter posisjonen. next() skal kaste NoSuchElementException hvis det ikke er mer.

public class Terningsett implements Iterable<Integer> {
    private final int[] verdier;

    public Terningsett(int... verdier) {
        this.verdier = verdier.clone();
    }

    @Override
    public Iterator<Integer> iterator() {
        return new Iterator<Integer>() {
            private int neste = 0;

            @Override
            public boolean hasNext() {
                return neste < verdier.length;
            }

            @Override
            public Integer next() {
                if (!hasNext()) {
                    throw new NoSuchElementException();
                }
                return verdier[neste++];
            }
        };
    }
}

hasNext() skal ikke ha bivirkninger — den kan kalles mange ganger på rad uten at posisjonen flytter seg. Det er en typisk plantet feil at telleren økes i hasNext().

Fail-fast og ConcurrentModificationException

Iteratorene til ArrayList, HashMap og de andre standardsamlingene er fail-fast: de teller strukturelle endringer, og oppdager de at samlingen er endret bakfra, kaster de ConcurrentModificationException ved neste next(). Derfor kræsjer dette:

for (Kort k : kortstokk) {
    if (k.erJoker()) {
        kort.remove(k);        // FEIL
    }
}

Tre lovlige løsninger: bruk iteratorens egen remove() via en eksplisitt Iterator-løkke, bruk kort.removeIf(Kort::erJoker), eller samle opp det som skal fjernes i en egen liste og kall removeAll etterpå.

Comparable: den naturlige ordningen

Implementerer klassen Comparable<T>, får den én innebygd sorteringsrekkefølge, og Collections.sort(liste), TreeSet og TreeMap virker uten videre. compareTo skal returnere et negativt tall hvis this kommer først, 0 ved likhet og et positivt tall ellers.

public class Emne implements Comparable<Emne> {
    private final int aar;
    private final char semester;   // 'V' eller 'H'

    @Override
    public int compareTo(Emne annet) {
        if (this.aar != annet.aar) {
            return Integer.compare(this.aar, annet.aar);
        }
        return Character.compare(this.semester, annet.semester);
    }
}

Bruk Integer.compare og Double.compare framfor subtraksjon. a - b kan renne over for store int-verdier, og for double gir en subtraksjon som havner mellom 0 og 1 avrunding til 0 når du caster til int — da påstår du at to ulike verdier er like. Kontrakten krever også at ordningen er konsistent: hvis a.compareTo(b) < 0 må b.compareTo(a) > 0, og helst skal compareTo returnere 0 nøyaktig når equals gir true.

Comparator: alternative ordninger

Trenger du flere sorteringer, eller kan du ikke endre klassen, lager du en Comparator<T>. Den er et funksjonelt grensesnitt, så den kan skrives som anonym klasse eller lambda, og Collections.sort(liste, comparator) tar den som argument.

public class Utoevere {

    public static Comparator<Utoever> paaNavn() {
        return (a, b) -> a.getNavn().compareTo(b.getNavn());
    }

    /** Flest gull foerst, saa flest soelv, saa flest bronse, saa navn. */
    public static Comparator<Utoever> paaMedaljer() {
        return (a, b) -> {
            for (String metall : List.of("Gull", "Soelv", "Bronse")) {
                int antallA = a.antall(metall);
                int antallB = b.antall(metall);
                if (antallA != antallB) {
                    return Integer.compare(antallB, antallA);   // synkende
                }
            }
            return paaNavn().compare(a, b);
        };
    }
}

Legg merke til to ting som gir poeng: flernivå-sammenligningen går videre til neste kriterium bare når det forrige er likt, og siste ledd faller tilbake på en annen comparator i stedet for å duplisere koden. Synkende rekkefølge får du ved å snu argumentene, ikke ved å sette minus foran.

Med hjelpemetodene blir det samme mye kortere:

Comparator<Utoever> c = Comparator
        .comparingInt((Utoever u) -> u.antall("Gull")).reversed()
        .thenComparing(Utoever::getNavn);

Comparable eller Comparator?

Standardspørsmålet «objektene skal kunne sorteres på to måter — forklar hvordan begge støttes» besvares slik: den ordningen som er den naturlige legges i klassen med Comparable, og den alternative lages som en Comparator (gjerne som en public static metode eller konstant i samme klasse). Da virker Collections.sort(liste) for standardordningen og Collections.sort(liste, Klasse.paaKarakter()) for den andre.

Studieguide: Iteratorer og sortering