DRY dans le développement mobile — ce que c'est, le principe et pourquoi la duplication est nuisible

Qu'est-ce que DRY ?

DRY (Don't Repeat Yourself) est un principe de développement qui exige de stocker chaque élément de connaissance dans un projet exactement une fois. Cela signifie que toute logique, configuration ou métadonnée doit exister en un seul endroit.

Le terme a été introduit par Andy Hunt et Dave Thomas en 1999 dans le livre «The Pragmatic Programmer». Les auteurs ont défini DRY comme «chaque partie de la connaissance doit avoir une représentation unique, sans ambiguïté et faisant autorité au sein du système». L'opposé de DRY est l'approche WET (Write Everything Twice), où la duplication est considérée comme normale.

Selon une étude de l'University of California, Davis (2019), les projets avec des niveaux élevés de duplication de code consacrent 42 % de temps en plus à la correction des bugs. La raison est que les développeurs doivent trouver et modifier toutes les copies du même fragment — et la recherche manuelle conduit inévitablement à des omissions.

Appliquez DRY comme critère de qualité du code. Si vous remarquez que le même motif apparaît trois fois dans un projet — extrayez-le dans une abstraction sans attendre une quatrième répétition.

Différence entre DRY et le principe de responsabilité unique

Le Principe de Responsabilité Unique (SRP) de SOLID stipule qu'une classe doit avoir une seule raison de changer. DRY est plus large : il couvre non seulement les classes, mais aussi les données, la configuration, la documentation et même les règles métier. SRP concerne les limites de responsabilité ; DRY concerne la prévention des copies.

Dans le développement mobile, cette distinction est particulièrement notable. Si la même règle métier (calcul d'impôt, formatage de date) se répète dans les parties Android et iOS du projet — c'est une violation de DRY, même si SRP est formellement respecté au sein de chaque plateforme. La solution est d'extraire la logique commune dans un module partagé (KMM, C++).

Selon le rapport Google Android Architecture Guidelines (2023), les équipes utilisant des modules partagés pour la logique métier réduisent le nombre de bugs lors des changements de spécifications de 37 % par rapport aux projets dupliquant la logique entre plateformes.

Pourquoi la duplication de code est-elle dangereuse ?

La duplication est la principale source de dette technique dans les projets mobiles. Chaque copie de code crée une dépendance cachée : pour changer le comportement, vous devez trouver et mettre à jour toutes les copies. En manquer une signifie un bug.

Considérez un scénario classique : dans une application Android, le formatage des dates est effectué dans trois Activities différentes. Lors du passage à un nouveau format (par exemple, ISO 8601), le développeur corrige deux fichiers, oublie le troisième — et l'utilisateur voit les dates dans l'ancien format. La note de l'application chute et trouver le bug prend deux fois plus de temps.

Une étude de Google Research (2020) a montré que 68 % des bugs critiques dans les applications mobiles sont liés à des modifications non synchronisées dans du code dupliqué. De plus, corriger un tel bug en production coûte 4,5 fois plus cher que si le code avait été unifié dès le départ.

Utilisez des analyseurs statiques (Detekt, SwiftLint) avec des règles qui détectent le copy-paste. Configurez le CI pour que les pull requests avec plus de N lignes de duplication ne passent pas la revue sans justification.

DRY dans le développement mobile : exemples pratiques

Duplication de logique UI dans Android

Un anti-patron typique consiste à copier un adaptateur RecyclerView avec des modifications mineures. Au lieu d'un adaptateur universel avec configuration, les développeurs créent une classe séparée pour chaque écran. Le refactoring en extrayant une classe de base commune réduit le code de 30 à 50 %.

// Duplication : deux adaptateurs séparés
class UserAdapter {
    fun bind(item: User) { /* ... */ }
}
class ProductAdapter {
    fun bind(item: Product) { /* ... */ }
}

// Refactoring DRY : classe de base commune
abstract class BaseAdapter<T> {
    abstract fun bind(item: T)
}
class UserAdapter : BaseAdapter<User>() { /* ... */ }
class ProductAdapter : BaseAdapter<Product>() { /* ... */ }

Dans le premier exemple, chaque adaptateur réimplémente le mécanisme bind à partir de zéro. Lors de l'ajout d'une nouvelle logique (analytique, journalisation), chaque fichier devrait être modifié. Une classe de base élimine cette duplication : la logique commune vit à un endroit, la logique spécifique dans les sous-classes.

Duplication des requêtes réseau dans iOS

Dans les projets iOS, la configuration URLSession — en-têtes, timeouts, gestion des erreurs — est souvent dupliquée. Chaque service crée sa propre session avec des paramètres répétés.

// Duplication : chaque service configure la session à nouveau
class UserService {
    let session = URLSession(configuration: {
        let cfg = URLSessionConfiguration.default
        cfg.timeoutIntervalForRequest = 30
        cfg.httpAdditionalHeaders = ["Authorization": "Bearer ..."]
        return cfg
    }())
}

// DRY : fabrique de sessions unifiée
struct NetworkConfig {
    static var session: URLSession {
        let cfg = URLSessionConfiguration.default
        cfg.timeoutIntervalForRequest = 30
        cfg.httpAdditionalHeaders = ["Authorization": "Bearer ..."]
        return URLSession(configuration: cfg)
    }
}

Extraire la configuration dans un NetworkConfig unifié garantit que tous les services utilisent les mêmes en-têtes et timeouts. Un changement à un endroit s'applique automatiquement à toutes les requêtes — cela réduit le risque d'erreurs lors du changement de clés API ou de versions de protocole.

Comment appliquer DRY dans Android et iOS ?

DRY par héritage et composition

L'héritage est un moyen naturel d'éliminer la duplication : la logique commune est déplacée vers une classe de base et la logique spécifique vers les sous-classes. Cependant, dans le développement mobile, l'abus d'héritage crée des hiérarchies rigides difficiles à maintenir. La composition (injection de dépendances) est une alternative plus flexible.

Une analyse de Google I/O 2023 : Modern Android Architecture a montré que 76 % des équipes Google préfèrent la composition à l'héritage pour éliminer la duplication. Au lieu d'un BaseViewModel avec une douzaine de méthodes, il est recommandé d'extraire des classes UseCase séparées pour chaque opération métier et de les injecter là où elles sont nécessaires.

Choisissez la composition dans tous les cas sauf les relations «est-un». Si la classe A est une spécialisation de la classe B — l'héritage est approprié. Si A utilise simplement la fonctionnalité de B — utilisez la composition.

DRY par classes utilitaires

Les classes utilitaires (Extensions, Helpers) sont le moyen le plus simple d'éviter la duplication. Candidats typiques : formatage de dates, validation d'email, conversion d'unités, travail avec SharedPreferences/UserDefaults.

// DRY : fonction unifiée de formatage de date
fun Date.toDisplayFormat(): String {
    val sdf = SimpleDateFormat("dd.MM.yyyy", Locale.getDefault())
    return sdf.format(this)
}

// Utilisation partout dans l'application
textView.text = Date().toDisplayFormat()

L'extension Date.toDisplayFormat() est déclarée une fois et disponible dans tout le projet. Si le format doit passer de «dd.MM.yyyy» à «yyyy-MM-dd» — la correction est dans un seul fichier, pas dans chaque Activity ou Fragment où le formatage a lieu. C'est l'essence de DRY.

DRY dans la configuration Gradle (Android)

Les projets Android multi-modules dupliquent souvent les versions de dépendances dans chaque build.gradle. La solution est un catalogue de versions (libs.versions.toml) qui centralise toutes les versions dans un seul fichier.

Selon la Documentation développeur Android (2024), la migration vers un catalogue de versions réduit les conflits de dépendances de 52 % et accélère les builds grâce à un point d'édition unique.

Implémentez un catalogue de versions au démarrage du projet ou lors de la première réorganisation des modules. Si le projet contient déjà de la duplication — consacrez une journée à la migration : elle sera rentabilisée lors de la prochaine mise à jour de bibliothèques.

Erreurs typiques lors de l'application de DRY

Abstraction prématurée

L'abstraction prématurée est l'erreur la plus courante des débutants. Un développeur voit deux lignes de code similaires et les extrait immédiatement dans une fonction commune. Un mois plus tard, les exigences changent et la fonction commune se retrouve surchargée de paramètres et de drapeaux — plus complexe que la duplication originale. La Règle de Trois protège exactement contre cela : n'abstrayez pas quelque chose qui n'est apparu qu'une ou deux fois.

Martin Fowler dans son livre Refactoring (2019) recommande : «La duplication de code n'est pas toujours mauvaise. La duplication de connaissance est mauvaise.» Si deux lignes coïncident par hasard mais expriment des concepts différents — ce n'est pas de la duplication, c'est une coïncidence. La Règle de Trois aide à distinguer la coïncidence accidentelle de la duplication systématique.

Avant d'abstraire, évaluez la sémantique. Du code copié avec le même sens — violation de DRY. Du code avec un sens différent mais une syntaxe similaire — coïncidence ne nécessitant pas d'abstraction.

Paramétrage excessif

Le paramétrage excessif se produit lorsqu'une seule fonction tente de couvrir tous les scénarios possibles via des drapeaux et des paramètres booléens. Un tel code viole SRP et devient illisible. Symptôme : si une fonction a plus de deux paramètres booléens — c'est un code smell d'abstraction excessive.

Au lieu d'une fonction avec un drapeau useCache: Boolean, il est préférable de créer deux fonctions séparées avec des noms clairs : fetchFromNetwork() et fetchFromCache(). La clarté est plus importante qu'une abstraction sèche — cela rejoint le principe KISS.

Refactorisez le paramétrage excessif lorsqu'une fonction atteint 3+ paramètres booléens. Divisez en fonctions séparées avec des noms clairs — chaque appel deviendra auto-documenté.