Interface: özü, Android için Java ve Kotlin'de sözleşmeler

Java ve Kotlin'de Interface Nedir?

Interface, soyut metotlar, sabitler ve varsayılan metotlar içeren bir referans türüdür. Bir arayüzü uygulayan sınıf, tüm soyut metotları için uygulama sağlamalıdır. Java'da bir arayüz durum (örnek alanları) içeremez; Kotlin de bu kısıtlamaya uyar ancak erişimcilerle özellikleri destekler.

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;
    // getter ve setter
}

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();
    }
    // diğer metotlar
}

Repository<T>, CRUD metotlarına sahip genel bir arayüzdür. default metot count(), geçersiz kılınabilen varsayılan bir uygulama sağlar. UserRepositoryImpl, veri erişimi için EntityManager kullanarak arayüzü uygular. Bu yaklaşım, gerçek bir veritabanı olmadan arayüz mock'u aracılığıyla veri katmanını test etmeye olanak tanır.

Interface vs abstract class: ne zaman ne seçilmeli

Bir arayüz ile soyut sınıf arasındaki seçim, paylaşılan durumun varlığına ve türler arasındaki ilişkilere bağlıdır. Arayüz bir sözleşme (bir sınıfın ne yapabileceği) tanımlar, soyut sınıf ortak bir uygulama (bir sınıfın ne olduğu) tanımlar.

Clean Architecture'de arayüzler iç katmana (domain) yerleştirilir ve uygulamalar dış katmana (data) yerleştirilir. Bu, Bağımlılık Kuralı'nı (Dependency Rule) korumaya olanak tanır: dış katman iç katmana bağlıdır, ancak tersi geçerli değildir. Soyut sınıflar daha çok şablon metotlar (Template Method pattern) için kullanılır.

Kotlin'de Interface: özellikler ve delegeler

Kotlin arayüzleri Java'dan daha esnektir: soyut özellikler bildirebilir ve metot uygulamaları sağlayabilir. Java'nın aksine Kotlin, by anahtar sözcüğü aracılığıyla delegasyonu destekler ve bu, Delegate modelini uygularken kalıplaşmış kodu büyük ölçüde azaltır.

interface ApiService {
    val baseUrl: String  // soyut özellik
    
    suspend fun fetchData(): Result>
    
    fun getEndpoint(path: String): String {
        return "$baseUrl/$path"  // varsayılan uygulama
    }
}

class RetrofitApiService(
    override val baseUrl: String
) : ApiService {
    private val client = Retrofit.Builder()
        .baseUrl(baseUrl)
        .build()
    
    override suspend fun fetchData(): Result> {
        // isteğin uygulanması
    }
}

// by ile delegasyon
interface Logger {
    fun log(message: String)
}

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

class UserService(logger: Logger) : Logger by logger

UserService, Logger arayüzünü delegasyon (by) yoluyla uygular. Tüm log() çağrıları, sarmalayıcı metotlar yazılmadan logger nesnesine yönlendirilir. Bu, Java'da 5-10 satır kalıplaşmış kod gerektirecek bir birleşim örneğidir.

Clean Architecture Android'de Interface

Clean Architecture for Android, uygulamayı açıkça katmanlara ayırır. Arayüzler katmanlar arasında sınır görevi görür: Domain, depo ve UseCase arayüzlerini tanımlar, Data uygulamaları sağlar. Bu, iş mantığını değiştirmeden uygulamaları değiştirmeye olanak tanır — Room'dan Firebase'e veya REST'ten GraphQL'e geçişte önemli bir avantaj.

// Domain layer — arayüz (sözleşme)
interface UserRepository {
    suspend fun getUser(id: String): User
    suspend fun updateUser(user: User)
}

// Domain layer — use case (arayüze bağlı)
class GetUserUseCase(
    private val repository: UserRepository
) {
    suspend operator fun invoke(id: String): Result {
        return runCatching { repository.getUser(id) }
    }
}

// Data layer — uygulama
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, domain katmanında bir arayüzdür. GetUserUseCase, uygulamaya değil arayüze bağlıdır. data katmanındaki UserRepositoryImpl, API ve yerel veritabanını birleştirerek arayüzü uygular. Bu mimari, veritabanı veya ağ kurmadan mock depo ile UseCases'i test etmeye olanak tanır.

Java 8+'da default ve static metotlar

Default metotlar, geriye dönük uyumluluğu bozmadan arayüzlerin evrimsel genişlemesi için Java 8'de eklenmiştir. ArrayList, Collection'a eklenen yeni stream() metodunu uygulamasaydı, eski kod çalışmaya devam ederdi. Arayüzlerdeki static metotlar, arayüzle ilgili yardımcı programlar olarak hizmet eder — yardımcı sınıflara bir alternatif.

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

Default metotlar elmas problemini (diamond problem) çözer: bir sınıf aynı default metoda sahip iki arayüz uygularsa, derleyici açık geçersiz kılma gerektirir. Static metotlar, arayüz adı aracılığıyla çağrılır — Vehicle.of("car") gibi, bir örnek olmadan.

Arayüz tasarımında yaygın hatalar

Arayüz tasarımındaki hatalar kırılgan koda, test karmaşıklığına ve SOLID ihlallerine yol açar. Üç yaygın soruna bakalım.

Interface Pollution — bir arayüzde çok fazla metot

15+ metot içeren bir arayüz, Interface Segregation Principle (ISP)'yi ihlal eder. Bir örnek, 10+ metotlu eski java.util.Dictionary'dir. Çözüm: birkaç küçük arayüze bölün — ReadableRepository, WritableRepository, SearchableRepository. Bir istemci (hizmet) yalnızca ihtiyaç duyduğu metotlara bağlıdır.

Aşırı soyutlama — her sınıf için arayüz

Gerçek bir çok biçimlilik ihtiyacı olmadan her sınıf için arayüz oluşturmak, Interface overkill anti-örüntüsüdür. Gösterge: arayüzün tam olarak bir uygulaması vardır ve projenin alternatif ekleme planı yoktur. Çözüm: yalnızca ikinci bir uygulama seçeneği göründüğünde veya testler için mock gerektiğinde arayüz ekleyin.