Antwoord.

Achtergrond

Java werd vanaf het begin ontwikkeld als een objectgeoriënteerde taal, waarbij de belangrijkste taak het creëren van class instanties was. Echter, voor vaak gebruikte methoden (zoals sorteren, data conversies) begonnen utility classes met een set statische methoden op te duiken (bijvoorbeeld java.util.Collections).

Probleem

Statische methoden vereenvoudigen het aanroepen van hulpfuncties, maar zijn niet geschikt voor het opslaan van state, dependency injection en isolatietests. Aan de andere kant zijn class instanties flexibeler, maar verhogen ze de hoeveelheid code voor initialisatie en vereisen ze een doordachte levenscyclus.

Oplossing

Utility classes — een set statische methoden zonder state, vereisen geen object creatie. Goed voor manipulaties met collecties, conversies, wiskundige operaties.
Class instanties — slaan state op, gebruiken dependencies, bieden uitbreidbaarheid en testbaarheid. Worden gebruikt in bedrijfslogica, services, controllers, enz.

Voorbeeld code:

// Voorbeeld utility class
public class MathUtils {
    public static int add(int a, int b) {
        return a + b;
    }
}

// Gebruik: int sum = MathUtils.add(1, 2);

// Voorbeeld class instantie voor bedrijfslogica
public class OrderService {
    private final OrderRepository repo;
    public OrderService(OrderRepository repo) {
        this.repo = repo;
    }
    public void placeOrder(Order o) {
        repo.save(o);
    }
}

Belangrijkste kenmerken:

Stateless en niet testbaar in isolatie — utility classes.
Klassen met state zijn gemakkelijk te vervangen via dependency injection (DI).
Utility classes worden vaak final gedeclareerd en hebben een private constructor.

Vragen met een twist.

Kun je utility classes erven en hun statische methoden uitbreiden?

Nee, utility classes worden doorgaans als final verklaard, met een private constructor. Het erven van statische methoden is mogelijk, maar heeft geen zin, omdat statische methoden niet worden geërfd op het niveau van de instance aanroep.

Voorbeeld code:

public final class MyUtils {
    private MyUtils() {} // voorkomt het maken van een instantie
}

Kunnen utility classes state bevatten?

Nee. Als een utility class state bevat (instance of static velden), schendt dit het principe van het schrijven van utilities, leidt het tot fouten in multi-threading en vermindert het de leesbaarheid.

Kun je statische methoden van utility classes moquen tijdens testen?

Alleen met speciale tools zoals PowerMock, die tests complexer en soms onbetrouwbaar maken. In normale gevallen is een DI-vriendelijke benadering met een instantie te verkiezen voor tests.

Veelvoorkomende fouten en antipatterns

Overtreding van het single responsibility-principe: utilities beginnen state op te slaan.
Erven of uitbreiden van utility classes.
Gebruik van statische methoden waar rekening moet worden gehouden met state (bijvoorbeeld zakelijke services).

Voorbeeld uit de praktijk

Negatief geval

In het project zijn alle services geïmplementeerd met behulp van utility statische methoden. Dependency injection is onmogelijk, unit tests zijn niet geïsoleerd, elke test is afhankelijk van de staat van de omgeving.

Voordelen:

Snelle start.
Eenvoud van aanroepen.

Nadelen:

Gebrek aan testbaarheid.
Problemen met het toewijzen van verantwoordelijkheden.

Positief geval

In de services worden afzonderlijke classes toegepast met dependency injection via interfaces. Voor conversies en eenvoudige handelingen worden aparte stateless utility classes gebruikt.