Principes d'architecture dans le développement mobile : ce qu'ils sont, leurs types et comment les appliquer

Principes SOLID

Les principes d'architecture sont le fondement d'un code de qualité. SOLID est un acronyme introduit par Robert Martin (« Oncle Bob ») décrivant cinq principes de conception orientée objet. Suivre SOLID rend le code plus flexible, testable et résistant au changement. La violation des principes d'architecture est l'une des principales causes de dette technique.

Examinons chaque principe. Single Responsibility Principle (SRP) — chaque classe ne doit avoir qu'une seule raison de changer. Open/Closed Principle (OCP) — les classes sont ouvertes à l'extension mais fermées à la modification. Liskov Substitution Principle (LSP) — les objets des sous-types doivent pouvoir remplacer les objets du type de base sans casser la logique. Interface Segregation Principle (ISP) — plusieurs interfaces spécialisées valent mieux qu'une interface générale. Dependency Inversion Principle (DIP) — dépendez des abstractions, pas des implémentations concrètes.

Selon l'analyse SonarQube (2025), la violation des principes SOLID se produit dans 68% des projets commerciaux. Les problèmes les plus courants sont la violation de SRP (35%) et d'ISP (22%). Chez IT Sectr, nous implémentons SOLID dès la phase de révision d'architecture — cela permet d'identifier les problèmes avant qu'ils ne se transforment en dette technique.

Single Responsibility Principle (SRP)

SRP (Principe de Responsabilité Unique) — le plus important et en même temps le principe SOLID le plus fréquemment violé. Il stipule : une classe ne doit avoir qu'une seule raison de changer. Si une classe fait trop de choses, il est difficile de la tester, de la modifier et de la comprendre.

Une violation typique est une classe qui traite simultanément des données, les sauvegarde dans la base de données et envoie des notifications par e-mail. L'exemple ci-dessous montre une violation de SRP en Kotlin et comment la corriger.

// Violation SRP — la classe fait trois choses différentes
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Validation des données
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Sauvegarde en base
        val user = User(email, name)
        database.save(user)
        
        // 3. Envoi de notification
        emailService.sendWelcomeEmail(email, name)
    }
}

// Correction — division en trois classes
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

Dans la version corrigée, chaque classe est responsable de sa propre tâche : UserValidator — de la validation, UserRepository — de la sauvegarde, NotificationService — des notifications. Cela rend le code testable et réutilisable — vous pouvez remplacer l'implémentation de la base de données sans modifier la logique de validation.

GRASP et Loi de Déméter

GRASP (General Responsibility Assignment Software Patterns) — neuf principes d'architecture pour répartir les responsabilités entre les objets, décrits par Craig Larman. Contrairement à SOLID, GRASP répond à la question « quelle classe devrait contenir cette méthode ? ». Modèles clés : Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Loi de Déméter (LoD, principe de couplage minimal) — une règle simple : un objet ne doit communiquer qu'avec ses voisins immédiats. Il ne faut pas écrire a.getB().getC().doSomething() — cela crée un fort couplage entre les classes. LoD améliore la réutilisabilité et simplifie les tests.

Chez IT Sectr, nous vérifions la conformité à LoD lors de la Revue de Code. Si une méthode « traverse » trois objets ou plus, c'est un signal que l'architecture doit être simplifiée. La violation de LoD est l'un des Code Smells les plus courants dans les grands projets.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) et YAGNI (You Ain't Gonna Need It) — trois principes d'architecture de base connus de tout développeur. Malgré leur simplicité, les violations se produisent constamment.

DRY — ne dupliquez pas le code. Si la même logique apparaît à deux endroits, extrayez-la dans une méthode ou une classe commune. La duplication est la principale source de bogues : une correction à un endroit est oubliée d'être appliquée à un autre. DRY ne signifie pas que vous ne pouvez pas avoir de code similaire — l'important est que la logique métier ne soit pas répétée.

KISS — plus c'est simple, mieux c'est. Les solutions complexes avec de nombreuses abstractions et héritages sont souvent excessives. Commencez par une solution simple et ne la complexifiez qu'en cas de besoin. YAGNI — n'écrivez pas de code pour des fonctionnalités qui pourraient être nécessaires « un jour plus tard ». Cela conduit à un gonflement de la base de code et à une complexité de maintenance accrue.

DRY — Don't Repeat Yourself

DRY — il ne s'agit pas seulement de l'absence de copier-coller. C'est un principe selon lequel chaque élément de connaissance ou de logique doit avoir une représentation unique et sans ambiguïté dans le système. La duplication peut être explicite (code copié) et implicite (même logique dans différentes couches).

Chez IT Sectr, nous utilisons des métriques d'analyse de code pour détecter la duplication. Des outils comme SonarQube et Detekt montrent le pourcentage de code dupliqué. Une valeur supérieure à 5% est un motif de refactoring. Cependant, il est important de se rappeler : DRY ne doit pas être atteint au prix de mauvaises abstractions — parfois, il vaut mieux laisser deux morceaux de code similaires tels quels si les combiner compliquerait la compréhension.

Séparation des préoccupations et Modularité

Séparation des préoccupations (SoC) — un principe d'architecture où un système est divisé en parties indépendantes (préoccupations), chacune résolvant sa propre tâche. Un exemple classique est la séparation en couches : présentation, logique métier, accès aux données. Chaque couche ne dépend que de la couche inférieure.

Modularité — le degré auquel un système peut être divisé en modules. Un module est un groupe de classes logiquement liées avec une interface bien définie. Les modules doivent être faiblement couplés (low coupling) et fortement cohésifs (high cohesion).

Cohésion vs Couplage

Cohésion — une mesure du degré de relation entre les éléments d'un même module. Une cohésion élevée est bonne : une classe fait une chose et le fait bien. Faible couplage — une mesure du degré d'indépendance des modules les uns par rapport aux autres. Un faible couplage est bon : modifier un module ne casse pas les autres.

L'architecture idéale est une cohésion élevée et un faible couplage. En pratique, cela signifie : une classe contient des méthodes qui travaillent sur les mêmes données (cohésion) et ne dépend que d'abstractions, pas d'implémentations concrètes (couplage). Un déséquilibre conduit à des « Objets Dieu » ou du « code spaghetti ».

Dette technique et Code Smell

Dette technique — une métaphore introduite par Ward Cunningham décrivant les « intérêts » qu'une équipe paie pour des décisions d'architecture sous-optimales et la violation des principes d'architecture. Comme la dette financière, la dette technique peut être intentionnelle (nous avons décidé de faire vite, nous referons plus tard) et non intentionnelle (mauvaise architecture due au manque d'expérience).

Code Smell — des signes superficiels de problèmes profonds dans le code. Le terme a été popularisé par Martin Fowler dans son livre « Refactoring ». Code Smells typiques : méthodes longues, grandes classes, longues chaînes d'appels, duplication de code, utilisation excessive de commentaires (au lieu d'un code clair).

Chez IT Sectr, la dette technique est suivie dans Jira sous forme de tâches séparées. Chaque sprint, nous consacrons 20% du temps au refactoring et au remboursement de la dette. Le travail systématique avec la dette technique est le seul moyen d'éviter une situation où l'ajout d'une nouvelle fonctionnalité prend plus de temps que son développement à partir de zéro.