runeflobakk

Tids-APIet f.o.m. Java 8 har konseptet Clock som gjør at man kan styre tidspunkter som resolves "fra miljøet/systemklokka" i tester. JodaTime gjør dette ved at man kaller på noen statiske metoder som globalt styrer hvordan JodaTime resolver tidspunkt hver gang man typisk ber om DateTime.now() eller tilsvarende. I Java Time API bruker man i stedet en instans av Clock. Jeg er mest fan av Java sin approach, selv om den kan virke mer tungvinn hvis man er vandt med "umiddelbarheten" ved å bare kalle på en statisk utility som overstyrer klokka globalt.

Grunner til at jeg foretrekker klokke-instans fremfor static metode for global styring er:

• man ser tydeligere at en klasse faktisk har en avhengighet til tiden, siden den må ha et eget Clock-felt, ev ta det inn i en metode.
• dersom det føles rart å ta inn en Clock så er det ofte også feil, og man bør ta inn en spesifikk tidsverdi som er resolvet utenfra. Det er ikke like le

runeflobakk

record Count<T>(T item, int count) {
    List<Count<T>> sumIf(BiPredicate<? super T, ? super T> shouldSum, Count<T> other) {
        return shouldSum.test(item, other.item) ? List.of(new Count<>(item, count + other.count)) : List.of(this, other);
    }
    @Override
    public String toString() {
        return "(\"" + item + "\"," + count + ")";
    }
}

runeflobakk

import com.tngtech.archunit.core.domain.JavaClass;
import com.tngtech.archunit.core.importer.ClassFileImporter;
import org.junit.jupiter.api.Test;

import static java.util.function.Function.identity;
import static java.util.function.Predicate.not;
import static java.util.stream.Collectors.joining;
import static java.util.stream.Collectors.toMap;

class InterfacesAndImplementors {