Interface: суть, контракти в Java та Kotlin для Android

Що таке Interface у Java та Kotlin?

Interface — це посилальний тип, що містить абстрактні методи, константи та методи за замовчуванням. Клас, що реалізує інтерфейс, зобов'язаний надати реалізацію всіх його абстрактних методів. У Java інтерфейс не може мати стан (поля екземпляра), Kotlin також дотримується цього обмеження, але підтримує властивості з аксесорами.

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;
    // геттери та сеттери
}

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();
    }
    // інші методи
}

Repository<T> — generic-інтерфейс з методами CRUD. Default-метод count() надає реалізацію за замовчуванням, яку можна перевизначити. UserRepositoryImpl реалізує інтерфейс, використовуючи EntityManager для доступу до даних. Такий підхід дозволяє тестувати шар даних через mock інтерфейсу без реальної БД.

Interface vs abstract class: коли що вибрати

Вибір між інтерфейсом та абстрактним класом залежить від наявності спільного стану та відносин між типами. Інтерфейс визначає контракт (що клас може робити), абстрактний клас — спільну реалізацію (чим клас є).

У Clean Architecture інтерфейси розміщуються у внутрішньому шарі (domain), а реалізації — у зовнішньому (data). Це дозволяє дотримуватися Dependency Rule: зовнішній шар залежить від внутрішнього, але не навпаки. Абстрактні класи частіше використовуються для шаблонних методів (Template Method pattern).

Interface у Kotlin: властивості та делегати

Інтерфейси Kotlin більш гнучкі, ніж Java: вони можуть оголошувати абстрактні властивості та надавати реалізації методів. На відміну від Java, Kotlin підтримує делегування через ключове слово by, що потужно скорочує шаблонний код при реалізації патерну Delegate.

interface ApiService {
    val baseUrl: String  // абстрактна властивість
    
    suspend fun fetchData(): Result>
    
    fun getEndpoint(path: String): String {
        return "$baseUrl/$path"  // реалізація за замовчуванням
    }
}

class RetrofitApiService(
    override val baseUrl: String
) : ApiService {
    private val client = Retrofit.Builder()
        .baseUrl(baseUrl)
        .build()
    
    override suspend fun fetchData(): Result> {
        // реалізація запиту
    }
}

// Делегування через 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 реалізує інтерфейс Logger через делегування (by). Всі виклики log() перенаправляються об'єкту logger без написання методів-обгорток. Це приклад композиції, яка в Java потребувала б 5-10 рядків шаблонного коду.

Interface у Clean Architecture Android

Clean Architecture для Android чітко розділяє застосунок на шари. Інтерфейси відіграють роль меж між шарами: Domain визначає інтерфейси репозиторіїв та UseCase, Data надає реалізації. Це дозволяє замінювати реалізації без зміни бізнес-логіки — ключова перевага при міграції з Room на Firebase або з REST на GraphQL.

// Domain layer — інтерфейс (контракт)
interface UserRepository {
    suspend fun getUser(id: String): User
    suspend fun updateUser(user: User)
}

// Domain layer — use case (залежить від інтерфейсу)
class GetUserUseCase(
    private val repository: UserRepository
) {
    suspend operator fun invoke(id: String): Result {
        return runCatching { repository.getUser(id) }
    }
}

// Data layer — реалізація
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-шарі. GetUserUseCase залежить від інтерфейсу, а не від реалізації. UserRepositoryImpl у data-шарі реалізує інтерфейс, комбінуючи API та локальну БД. Така архітектура дозволяє тестувати UseCase з mock-репозиторієм без налаштування бази даних або мережі.

Default та static методи в Java 8+

Default методи були додані в Java 8 для еволюційного розширення інтерфейсів без порушення зворотної сумісності. Якби ArrayList не реалізовував новий метод stream(), доданий до Collection, старий код продовжив би працювати. Static методи в інтерфейсах служать для утиліт, що належать до інтерфейсу, — альтернатива класам-утилітам.

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();
    }
    
    // константа
    String CATEGORY = "transport";
}

Default-методи вирішують diamond problem: якщо клас реалізує два інтерфейси з однаковим default-методом, компілятор вимагає явного перевизначення. Static-методи викликаються через ім'я інтерфейсу — Vehicle.of("car"), без екземпляра.

Типові помилки при проєктуванні інтерфейсів

Помилки в проєктуванні інтерфейсів призводять до крихкого коду, складності тестування та порушень SOLID. Розглянемо три поширені проблеми.

Interface Pollution — забагато методів в одному інтерфейсі

Інтерфейс, що містить 15+ методів, порушує Interface Segregation Principle (ISP). Приклад — старий java.util.Dictionary з 10+ методами. Рішення: розділити на кілька дрібних інтерфейсів — ReadableRepository, WritableRepository, SearchableRepository. Клієнт (сервіс) залежить тільки від потрібних йому методів.

Надмірна абстракція — інтерфейс під кожен клас

Створення інтерфейсу для кожного класу без реальної потреби в поліморфізмі — антипатерн Interface overkill. Ознака: в інтерфейсу рівно одна реалізація, і в проєкті немає планів щодо додавання альтернатив. Рішення: додавати інтерфейс тільки коли з'являється другий варіант реалізації або потреба в mock для тестів.