Interface: essentie, contracten in Java en Kotlin voor Android

Wat is Interface in Java en Kotlin?

Interface — is een referentietype dat abstracte methoden, constanten en standaardmethoden bevat. Een klasse die een interface implementeert, moet de implementatie van al zijn abstracte methoden leveren. In Java kan een interface geen toestand hebben (instantievelden), Kotlin volgt deze beperking ook, maar ondersteunt eigenschappen met accessors.

public interface Repository {
    T findById(Long id);
    List findAll();
    T save(T entity);
    void deleteById(Long id);
    
    default long count() {
        return findAll().size();
    }
}

@Entity
public class UserEntity {
    private Long id;
    private String email;
    // getters en setters
}

public class UserRepositoryImpl implements Repository {
    private final EntityManager em;
    
    public UserEntity findById(Long id) {
        return em.find(UserEntity.class, id);
    }
    
    public List findAll() {
        return em.createQuery("FROM UserEntity", UserEntity.class)
                .getResultList();
    }
    // overige methoden
}

Repository<T> — een generieke interface met CRUD-methoden. De default-methode count() biedt een standaardimplementatie die kan worden overschreven. UserRepositoryImpl implementeert de interface met EntityManager voor gegevenstoegang. Deze aanpak maakt het mogelijk om de gegevenslaag te testen via een mock van de interface zonder echte database.

Interface vs abstract class: wanneer wat te kiezen

De keuze tussen een interface en een abstracte klasse hangt af van de aanwezigheid van gedeelde toestand en relaties tussen typen. Een interface definieert een contract (wat een klasse kan doen), een abstracte klasse — een gemeenschappelijke implementatie (wat een klasse is).

In Clean Architecture bevinden interfaces zich in de binnenste laag (domain) en implementaties in de buitenste laag (data). Dit maakt naleving van de Dependency Rule mogelijk: de buitenste laag is afhankelijk van de binnenste, niet andersom. Abstracte klassen worden vaker gebruikt voor sjabloonmethoden (Template Method pattern).

Interface in Kotlin: eigenschappen en delegaten

Kotlin-interfaces zijn flexibeler dan Java: ze kunnen abstracte eigenschappen declareren en methodimplementaties bieden. In tegenstelling tot Java ondersteunt Kotlin delegatie via het sleutelwoord by, wat boilerplate aanzienlijk vermindert bij het implementeren van het Delegate-patroon.

interface ApiService {
    val baseUrl: String  // abstracte eigenschap
    
    suspend fun fetchData(): Result>
    
    fun getEndpoint(path: String): String {
        return "$baseUrl/$path"  // standaardimplementatie
    }
}

class RetrofitApiService(
    override val baseUrl: String
) : ApiService {
    private val client = Retrofit.Builder()
        .baseUrl(baseUrl)
        .build()
    
    override suspend fun fetchData(): Result> {
        // implementatie van de aanvraag
    }
}

// Delegatie via by
interface Logger {
    fun log(message: String)
}

class ConsoleLogger : Logger {
    override fun log(message: String) = println(message)
}

class UserService(logger: Logger) : Logger by logger

UserService implementeert de Logger-interface via delegatie (by). Alle log()-aanroepen worden doorgestuurd naar het logger-object zonder wrapper-methoden te schrijven. Dit is een voorbeeld van compositie die in Java 5-10 regels boilerplate-code zou vereisen.

Interface in Clean Architecture Android

Clean Architecture voor Android verdeelt de applicatie duidelijk in lagen. Interfaces fungeren als grenzen tussen lagen: Domain definieert interfaces voor repositories en UseCases, Data levert implementaties. Dit maakt het mogelijk om implementaties te vervangen zonder de bedrijfslogica te wijzigen — een belangrijk voordeel bij migratie van Room naar Firebase of van REST naar GraphQL.

// Domain-laag — interface (contract)
interface UserRepository {
    suspend fun getUser(id: String): User
    suspend fun updateUser(user: User)
}

// Domain-laag — use case (afhankelijk van interface)
class GetUserUseCase(
    private val repository: UserRepository
) {
    suspend operator fun invoke(id: String): Result {
        return runCatching { repository.getUser(id) }
    }
}

// Data-laag — implementatie
class UserRepositoryImpl(
    private val api: UserApi,
    private val dao: UserDao
) : UserRepository {
    override suspend fun getUser(id: String): User {
        val cached = dao.getUser(id)
        if (cached != null) return cached
        val remote = api.fetchUser(id)
        dao.insertUser(remote)
        return remote
    }
    // updateUser...
}

UserRepository — interface in de domain-laag. GetUserUseCase is afhankelijk van de interface, niet van de implementatie. UserRepositoryImpl in de data-laag implementeert de interface en combineert API en lokale database. Deze architectuur maakt het mogelijk om UseCases te testen met een mock-repository zonder database- of netwerkconfiguratie.

Default en static methoden in Java 8+

Default methoden zijn toegevoegd in Java 8 voor evolutionaire uitbreiding van interfaces zonder achterwaartse compatibiliteit te schenden. Als ArrayList de nieuwe stream()-methode die aan Collection was toegevoegd niet had geïmplementeerd, zou oude code blijven werken. Static methoden in interfaces dienen voor hulpprogramma's die bij de interface horen — een alternatief voor utility-klassen.

public interface Vehicle {
    void start();
    void stop();
    
    default void honk() {
        System.out.println("Beep!");
    }
    
    static Vehicle of(String type) {
        if ("car".equals(type)) return new Car();
        return new Bicycle();
    }
    
    // constante
    String CATEGORY = "transport";
}

Default-methoden lossen het diamond problem op: als een klasse twee interfaces met dezelfde default-methode implementeert, vereist de compiler expliciete overschrijving. Static-methoden worden aangeroepen via de interfacenaam — Vehicle.of("car"), zonder instantie.

Veelgemaakte fouten bij het ontwerpen van interfaces

Fouten bij het ontwerpen van interfaces leiden tot breekbare code, testproblemen en SOLID-schendingen. Laten we drie veelvoorkomende problemen bekijken.

Interface Pollution — te veel methoden in één interface

Een interface met 15+ methoden schendt het Interface Segregation Principle (ISP). Voorbeeld — de oude java.util.Dictionary met 10+ methoden. Oplossing: splitsen in meerdere kleine interfaces — ReadableRepository, WritableRepository, SearchableRepository. De klant (service) is alleen afhankelijk van de methoden die hij nodig heeft.

Overmatige abstractie — interface voor elke klasse

Het maken van een interface voor elke klasse zonder echte behoefte aan polymorfisme is het antipatroon Interface overkill. Kenmerk: de interface heeft precies één implementatie en er zijn geen plannen om alternatieven toe te voegen. Oplossing: voeg een interface alleen toe wanneer er een tweede implementatievariant ontstaat of behoefte is aan een mock voor tests.