Interface: esența, contracte în Java și Kotlin pentru Android

Ce este Interface în Java și Kotlin?

Interface — este un tip de referință care conține metode abstracte, constante și metode implicite. Clasa care implementează interfața este obligată să furnizeze implementarea tuturor metodelor sale abstracte. În Java, interfața nu poate avea stare (câmpuri de instanță), Kotlin respectă și el această restricție, dar suportă proprietăți cu accesori.

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;
    // gettere și settere
}

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();
    }
    // celelalte metode
}

Repository<T> — o interfață generică cu metode CRUD. Metoda implicită count() oferă o implementare implicită care poate fi suprascrisă. UserRepositoryImpl implementează interfața, folosind EntityManager pentru accesul la date. Această abordare permite testarea stratului de date printr-un mock al interfeței fără o bază de date reală.

Interface vs abstract class: când să alegi ce

Alegerea între interfață și clasa abstractă depinde de existența stării comune și a relațiilor dintre tipuri. Interfața definește un contract (ce poate face clasa), clasa abstractă — o implementare comună (ce este clasa).

În Clean Architecture interfețele sunt plasate în stratul interior (domain), iar implementările — în stratul exterior (data). Aceasta permite respectarea Regulii Dependenței: stratul exterior depinde de cel interior, dar nu invers. Clasele abstracte sunt folosite mai des pentru metode șablon (Template Method pattern).

Interface în Kotlin: proprietăți și delegați

Interfețele Kotlin sunt mai flexible decât în Java: pot declara proprietăți abstracte și pot oferi implementări de metode. Spre deosebire de Java, Kotlin suportă delegarea prin cuvântul cheie by, ceea ce reduce semnificativ boilerplate-ul la implementarea pattern-ului Delegate.

interface ApiService {
    val baseUrl: String  // proprietate abstractă
    
    suspend fun fetchData(): Result>
    
    fun getEndpoint(path: String): String {
        return "$baseUrl/$path"  // implementare implicită
    }
}

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

// Delegare prin 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 implementează interfața Logger prin delegare (by). Toate apelurile log() sunt redirecționate către obiectul logger fără a scrie metode wrapper. Acesta este un exemplu de compoziție care în Java ar necesita 5-10 linii de cod boilerplate.

Interface în Clean Architecture Android

Clean Architecture pentru Android separă clar aplicația în straturi. Interfețele joacă rolul de granițe între straturi: Domain definește interfețele repository-urilor și UseCase-urilor, Data oferă implementări. Aceasta permite înlocuirea implementărilor fără a modifica logica de business — un avantaj cheie la migrarea de la Room la Firebase sau de la REST la GraphQL.

// Stratul Domain — interfață (contract)
interface UserRepository {
    suspend fun getUser(id: String): User
    suspend fun updateUser(user: User)
}

// Stratul Domain — use case (depinde de interfață)
class GetUserUseCase(
    private val repository: UserRepository
) {
    suspend operator fun invoke(id: String): Result {
        return runCatching { repository.getUser(id) }
    }
}

// Stratul Data — implementare
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 — interfață în stratul domain. GetUserUseCase depinde de interfață, nu de implementare. UserRepositoryImpl în stratul data implementează interfața, combinând API și baza de date locală. O astfel de arhitectură permite testarea UseCase-urilor cu un repository mock fără configurarea bazei de date sau a rețelei.

Metode Default și static în Java 8+

Metodele default au fost adăugate în Java 8 pentru extinderea evolutivă a interfețelor fără a încălca compatibilitatea inversă. Dacă ArrayList nu ar fi implementat noua metodă stream() adăugată în Collection, codul vechi ar fi continuat să funcționeze. Metodele static în interfețe servesc pentru utilități legate de interfață — o alternativă la clasele utilitare.

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();
    }
    
    // constantă
    String CATEGORY = "transport";
}

Metodele default rezolvă problema diamantului (diamond problem): dacă o clasă implementează două interfețe cu aceeași metodă default, compilatorul solicită suprascrierea explicită. Metodele static sunt apelate prin numele interfeței — Vehicle.of("car"), fără instanță.

Greșeli tipice la proiectarea interfețelor

Greșelile în proiectarea interfețelor duc la cod fragil, dificultăți de testare și încălcări ale SOLID. Să analizăm trei probleme frecvente.

Interface Pollution — prea multe metode într-o singură interfață

O interfață cu 15+ metode încalcă Interface Segregation Principle (ISP). Exemplu — vechiul java.util.Dictionary cu 10+ metode. Soluție: împărțirea în mai multe interfețe mici — ReadableRepository, WritableRepository, SearchableRepository. Clientul (serviciul) depinde doar de metodele de care are nevoie.

Abstractizare excesivă — interfață pentru fiecare clasă

Crearea unei interfețe pentru fiecare clasă fără nevoia reală de polimorfism este anti-pattern-ul Interface overkill. Semn: interfața are exact o implementare și nu există planuri de adăugare a alternativelor în proiect. Soluție: adăugați interfață doar când apare a doua variantă de implementare sau nevoia de mock pentru teste.