Principes SOLID en Kotlin : théorie et pratique avec exemples de code

Principes SOLID en Kotlin : de la théorie à la pratique

SOLID est l'acronyme de cinq principes fondamentaux de conception orientée objet, formulés par Robert Martin (Uncle Bob). Ces principes aident à créer un code flexible, évolutif et facile à maintenir. Dans cet article, nous allons analyser chaque principe SOLID avec des exemples tirés du monde Kotlin, afin que vous puissiez les appliquer immédiatement dans vos projets.

1. Single Responsibility Principle (SRP) — Principe de responsabilité unique

Théorie : Chaque classe ne doit avoir qu'une seule raison de changer. Autrement dit, une classe doit être responsable d'une fonctionnalité clairement définie.

Pratique en Kotlin : Considérons une violation typique du SRP, où une classe s'occupe à la fois du traitement des données, de l'affichage et de la validation.

// ❌ Violation du SRPclass UserManager {    fun registerUser(email: String, password: String) {        if (isValidEmail(email) && isValidPassword(password)) {            saveToDatabase(email, password)            sendWelcomeEmail(email)        }    }

    private fun isValidEmail(email: String): Boolean = email.contains("@")    private fun isValidPassword(password: String): Boolean = password.length >= 6    private fun saveToDatabase(email: String, password: String) { /* ... */ }    private fun sendWelcomeEmail(email: String) { /* ... */ }}

Refactorisation respectant le SRP :

// ✅ Respect du SRPclass UserValidator {    fun isValidEmail(email: String): Boolean = email.contains("@")    fun isValidPassword(password: String): Boolean = password.length >= 6}

class UserRepository {    fun save(email: String, password: String) { /* Sauvegarde en BDD */ }}

class EmailService {    fun sendWelcomeEmail(email: String) { /* Envoi d'email */ }}

class UserRegistrationService(    private val validator: UserValidator,    private val repository: UserRepository,    private val emailService: EmailService) {    fun registerUser(email: String, password: String) {        if (validator.isValidEmail(email) && validator.isValidPassword(password)) {            repository.save(email, password)            emailService.sendWelcomeEmail(email)        }    }}

2. Open/Closed Principle (OCP) — Principe d'ouverture/fermeture

Théorie : Les entités logicielles (classes, modules, fonctions) doivent être ouvertes à l'extension, mais fermées à la modification. Vous devez pouvoir ajouter de nouvelles fonctionnalités sans modifier le code existant.

Pratique en Kotlin : Utilisons des interfaces et le polymorphisme. Au lieu de if-else ou when pour traiter différents types, créons une hiérarchie.

// ❌ Violation de l'OCPclass DiscountCalculator {    fun calculateDiscount(customerType: String, amount: Double): Double {        return when (customerType) {            "Regular" -> amount * 0.05            "Premium" -> amount * 0.10            "VIP" -> amount * 0.20            else -> 0.0        }    }    // Pour ajouter "Gold", il faut modifier cette méthode !}

// ✅ Respect de l'OCPinterface DiscountStrategy {    fun applyDiscount(amount: Double): Double}

class RegularDiscount : DiscountStrategy {    override fun applyDiscount(amount: Double): Double = amount * 0.05}

class PremiumDiscount : DiscountStrategy {    override fun applyDiscount(amount: Double): Double = amount * 0.10}

class VIPDiscount : DiscountStrategy {    override fun applyDiscount(amount: Double): Double = amount * 0.20}

// Nouveau type ajouté sans modifier le code existantclass GoldDiscount : DiscountStrategy {    override fun applyDiscount(amount: Double): Double = amount * 0.15}

class DiscountCalculator {    fun calculateDiscount(strategy: DiscountStrategy, amount: Double): Double {        return strategy.apply