Interface: essência, contratos em Java e Kotlin para Android

O que é Interface em Java e Kotlin?

Interface é um tipo de referência que contém métodos abstratos, constantes e métodos padrão. Uma classe que implementa uma interface deve fornecer implementação para todos os seus métodos abstratos. Em Java, uma interface não pode ter estado (campos de instância); Kotlin também segue essa restrição, mas suporta propriedades com acessores.

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 e 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();
    }
    // outros métodos
}

Repository<T> é uma interface genérica com métodos CRUD. O método default count() fornece uma implementação padrão que pode ser sobrescrita. UserRepositoryImpl implementa a interface usando EntityManager para acesso a dados. Essa abordagem permite testar a camada de dados através de um mock da interface sem um banco de dados real.

Interface vs abstract class: quando escolher o quê

A escolha entre uma interface e uma classe abstrata depende da presença de estado compartilhado e das relações entre tipos. Uma interface define um contrato (o que uma classe pode fazer), uma classe abstrata define uma implementação comum (o que uma classe é).

No Clean Architecture, as interfaces são colocadas na camada interna (domain), e as implementações na camada externa (data). Isso permite manter a Dependency Rule: a camada externa depende da interna, mas não o contrário. Classes abstratas são mais usadas para métodos template (Template Method pattern).

Interface em Kotlin: propriedades e delegados

As interfaces do Kotlin são mais flexíveis que as do Java: podem declarar propriedades abstratas e fornecer implementações de métodos. Diferente do Java, Kotlin suporta delegação através da palavra-chave by, o que reduz poderosamente o boilerplate ao implementar o padrão Delegate.

interface ApiService {
    val baseUrl: String  // propriedade abstrata
    
    suspend fun fetchData(): Result>
    
    fun getEndpoint(path: String): String {
        return "$baseUrl/$path"  // implementação padrão
    }
}

class RetrofitApiService(
    override val baseUrl: String
) : ApiService {
    private val client = Retrofit.Builder()
        .baseUrl(baseUrl)
        .build()
    
    override suspend fun fetchData(): Result> {
        // implementação da solicitação
    }
}

// Delegação 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 implementa a interface Logger através de delegação (by). Todas as chamadas log() são redirecionadas para o objeto logger sem escrever métodos wrapper. Este é um exemplo de composição que em Java exigiria 5-10 linhas de código boilerplate.

Interface no Clean Architecture Android

Clean Architecture para Android separa claramente o aplicativo em camadas. As interfaces atuam como limites entre camadas: Domain define as interfaces de repositórios e UseCases, Data fornece as implementações. Isso permite substituir implementações sem alterar a lógica de negócio — uma vantagem chave ao migrar de Room para Firebase ou de REST para GraphQL.

// Domain layer — interface (contrato)
interface UserRepository {
    suspend fun getUser(id: String): User
    suspend fun updateUser(user: User)
}

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

// Data layer — implementação
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 é uma interface na camada domain. GetUserUseCase depende da interface, não da implementação. UserRepositoryImpl na camada data implementa a interface, combinando API e banco de dados local. Essa arquitetura permite testar UseCases com um repositório mock sem configurar banco de dados ou rede.

Métodos default e static no Java 8+

Os métodos default foram adicionados no Java 8 para extensão evolutiva de interfaces sem quebrar a compatibilidade reversa. Se ArrayList não implementasse o novo método stream() adicionado ao Collection, o código antigo continuaria funcionando. Métodos static em interfaces servem como utilitários relacionados à interface — uma alternativa a classes utilitárias.

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";
}

Os métodos default resolvem o diamond problem: se uma classe implementa duas interfaces com o mesmo método default, o compilador exige sobrescrita explícita. Métodos static são chamados através do nome da interface — Vehicle.of("car"), sem uma instância.

Erros comuns no design de interfaces

Erros no design de interfaces levam a código frágil, complexidade de teste e violações SOLID. Vamos ver três problemas comuns.

Interface Pollution — muitos métodos em uma interface

Uma interface contendo 15+ métodos viola o Interface Segregation Principle (ISP). Um exemplo é o antigo java.util.Dictionary com 10+ métodos. Solução: dividir em várias interfaces pequenas — ReadableRepository, WritableRepository, SearchableRepository. Um cliente (serviço) depende apenas dos métodos que precisa.

Abstração excessiva — interface para cada classe

Criar uma interface para cada classe sem necessidade real de polimorfismo é o antipadrão Interface overkill. Indicador: a interface tem exatamente uma implementação e o projeto não tem planos de adicionar alternativas. Solução: adicionar uma interface apenas quando uma segunda opção de implementação aparecer ou um mock for necessário para testes.