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;
    // getters και 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();
    }
    // υπόλοιπες μέθοδοι
}

Repository<T> — μια γενική διεπαφή με μεθόδους CRUD. Η προεπιλεγμένη μέθοδος count() παρέχει μια προεπιλεγμένη υλοποίηση που μπορεί να παρακαμφθεί. Το UserRepositoryImpl υλοποιεί τη διεπαφή, χρησιμοποιώντας EntityManager για πρόσβαση σε δεδομένα. Αυτή η προσέγγιση επιτρέπει τη δοκιμή του επιπέδου δεδομένων μέσω mock της διεπαφής χωρίς πραγματική βάση δεδομένων.

Interface vs abstract class: πότε να διαλέξεις τι

Η επιλογή μεταξύ διεπαφής και αφηρημένης κλάσης εξαρτάται από την ύπαρξη κοινής κατάστασης και σχέσεων μεταξύ τύπων. Η διεπαφή ορίζει ένα συμβόλαιο (τι μπορεί να κάνει η κλάση), η αφηρημένη κλάση — μια κοινή υλοποίηση (τι είναι η κλάση).

Στην Clean Architecture, οι διεπαφές τοποθετούνται στο εσωτερικό επίπεδο (domain), και οι υλοποιήσεις — στο εξωτερικό (data). Αυτό επιτρέπει την τήρηση του Κανόνα Εξάρτησης: το εξωτερικό επίπεδο εξαρτάται από το εσωτερικό, όχι το αντίστροφο. Οι αφηρημένες κλάσεις χρησιμοποιούνται συχνότερα για μεθόδους προτύπου (Template Method pattern).

Interface σε Kotlin: ιδιότητες και εκπρόσωποι

Οι διεπαφές Kotlin είναι πιο ευέλικτες από της Java: μπορούν να δηλώνουν αφηρημένες ιδιότητες και να παρέχουν υλοποιήσεις μεθόδων. Σε αντίθεση με τη Java, η Kotlin υποστηρίζει εκπροσώπηση μέσω της λέξης-κλειδιού by, μειώνοντας σημαντικά τον boilerplate κώδικα κατά την υλοποίηση του προτύπου 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 χωρίς να γράφονται μέθοδοι wrapper. Αυτό είναι ένα παράδειγμα σύνθεσης που σε Java θα απαιτούσε 5-10 γραμμές boilerplate κώδικα.

Interface στην Clean Architecture Android

Clean Architecture για Android χωρίζει ξεκάθαρα την εφαρμογή σε επίπεδα. Οι διεπαφές παίζουν ρόλο συνόρων μεταξύ επιπέδων: το Domain ορίζει διεπαφές αποθετηρίων και UseCase, το Data παρέχει υλοποιήσεις. Αυτό επιτρέπει την αντικατάσταση υλοποιήσεων χωρίς αλλαγή επιχειρηματικής λογικής — βασικό πλεονέκτημα κατά τη μετάβαση από Room σε Firebase ή από REST σε GraphQL.

// Επίπεδο Domain — διεπαφή (συμβόλαιο)
interface UserRepository {
    suspend fun getUser(id: String): User
    suspend fun updateUser(user: User)
}

// Επίπεδο Domain — use case (εξαρτάται από διεπαφή)
class GetUserUseCase(
    private val repository: UserRepository
) {
    suspend operator fun invoke(id: String): Result {
        return runCatching { repository.getUser(id) }
    }
}

// Επίπεδο Data — υλοποίηση
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 σε δοκιμές.