Separation of Concerns dans le développement mobile — ce que c'est, principes et application

Qu'est-ce que Separation of Concerns

Separation of Concerns est un principe de décomposition d'un système logiciel en parties indépendantes, chacune résolvant une tâche. Le terme concern (domaine de responsabilité) désigne toute partie séparable de la fonctionnalité : affichage d'écran, traitement des appuis, validation des données ou communication réseau. Le principe dicte de regrouper le code de sorte que les changements dans un domaine n'exigent pas de changements dans les autres.

Dans le développement mobile, SoC se manifeste à plusieurs niveaux : de la division de l'application en écrans à l'organisation du code au sein d'une seule classe. Une Activity ou ViewController qui charge simultanément des données depuis le réseau, analyse du JSON et rend l'IU viole Separation of Concerns — ce code est difficile à maintenir, tester et étendre. L'alternative est d'extraire chaque responsabilité dans un composant séparé.

Le principe est étroitement lié au concept d'abstraction : chaque couche fournit une interface strictement définie et cache les détails d'implémentation. Grâce à cela, un développeur peut remplacer une bibliothèque réseau ou une base de données sans réécrire la logique d'IU. C'est particulièrement précieux dans les projets à longue durée de vie où les exigences et les technologies évoluent avec le temps.

Histoire et origine du principe

Edsger Dijkstra a formulé pour la première fois l'idée de Separation of Concerns dans son article de 1974 « On the Role of Scientific Thought ». Il soutenait que la complexité des systèmes logiciels peut être contrôlée en les divisant en parties qui sont analysées isolément. Cette approche contrastait avec les programmes monolithiques de l'époque, où le code mélangeait calcul, entrée-sortie et interface utilisateur.

Dans les années 1980, l'idée a été développée par les partisans de la programmation structurée, puis par l'approche orientée objet. Des langages comme Smalltalk et C++ ont fourni des mécanismes d'encapsulation et de modularité qui ont fait de SoC un outil pratique. Les patrons architecturaux modernes — MVC, MVP, MVVM et Clean Architecture — sont des incarnations directes du principe Separation of Concerns.

Dans le monde du développement mobile, Apple a promu MVC comme standard pour iOS, où Model-View-Controller sépare les données, l'affichage et la logique de contrôle. Google pour Android a proposé des directives architecturales basées sur ViewModel et Repository — chaque composant résout sa propre tâche spécifique. Sans SoC, les applications mobiles se transforment en Massive View Controller — des classes de milliers de lignes où tout changement risque de casser toutes les fonctionnalités.

Niveaux de séparation dans l'architecture mobile

Quatre couches principales forment une architecture typique d'application mobile implémentant Separation of Concerns. Chaque couche est responsable uniquement de son domaine et interagit avec les voisines via des interfaces.

Couche IU : Vue et ViewModel

La Vue est exclusivement responsable de l'affichage des données et du traitement des événements utilisateur. Sous iOS, c'est UIViewController et UIView, sous Android — Fragment ou Activity. ViewModel contient l'état de l'écran et la logique de transformation des données dans un format prêt à l'affichage. La séparation garantit que remplacer UIKit par SwiftUI ou réécrire un écran avec Jetpack Compose n'affecte pas la logique métier.

Tester ViewModel ne nécessite pas d'exécuter un émulateur ou simulateur — des tests unitaires qui vérifient la transformation des données et la réponse aux actions utilisateur sont suffisants. C'est une conséquence directe de Separation of Concerns : l'IU n'est pas mélangée aux règles métier, et chaque composant est testé isolément.

Couche de logique métier : Cas d'utilisation et Interacteurs

Le Cas d'utilisation (ou Interacteur) contient les règles métier de l'application — calculs, validations, orchestration des appels de données. Cette couche ignore l'existence de l'IU ou des frameworks de la plateforme. Le Cas d'utilisation reçoit les données du Repository, leur applique la logique et retourne le résultat final à ViewModel. La séparation permet de réutiliser un même Cas d'utilisation sur différents écrans.

Par exemple, LoginUseCase vérifie la validité de l'email, appelle AuthRepository pour l'authentification et retourne le résultat. Il ne dépend pas de l'apparence de l'écran de connexion — SwiftUI, UIKit ou Compose. Si les règles métier changent, il suffit de modifier un Cas d'utilisation sans toucher à l'IU ni à la base de données.

Couche de données : Repository et DataSource

Repository abstrait les sources de données : API distante, base de données locale ou cache mémoire. ViewModel et le Cas d'utilisation ne savent pas d'où viennent exactement les données — Repository décide s'il charge depuis le réseau ou depuis le cache. Cette séparation permet de changer l'implémentation du stockage sans affecter la logique métier ni l'IU.

DataSource est une séparation encore plus bas niveau : NetworkDataSource est responsable uniquement des requêtes HTTP, LocalDataSource — de travailler avec Room ou CoreData. Repository combine les appels à différents DataSources en une interface cohérente unique. Chaque DataSource est testé indépendamment à l'aide de mocks ou de serveurs factices.

L'implémentation correcte de la couche DataSource garantit que modifier le schéma de la base de données ou remplacer REST API par GraphQL n'affecte qu'un seul DataSource, mais pas le Repository ni ses consommateurs. C'est une conséquence directe de Separation of Concerns au niveau de l'infrastructure : chaque préoccupation technique est isolée et remplaçable sans modifications en cascade.

SoC dans les patrons de conception

MVVM (Model-View-ViewModel) est le patron le plus populaire pour le développement mobile, implémentant directement Separation of Concerns. Model contient les données et la logique métier, View est responsable de l'affichage, et ViewModel les connecte via des mécanismes réactifs. Dans Flutter, BLoC joue un rôle similaire avec une séparation en événements, états et logique métier.

Clean Architecture de Robert Martin (Uncle Bob) pousse SoC à son maximum : le système est divisé en anneaux indépendants — entités, cas d'utilisation, adaptateurs et frameworks. Les anneaux internes (entités) ne dépendent pas des anneaux externes (frameworks). Cela permet de changer la base de données, le framework d'IU et même la plateforme sans réécrire la logique centrale de l'application.

En pratique, les projets mobiles implémentent rarement Clean Architecture complète — pour la plupart des applications, une architecture à trois couches est suffisante : IU, Domaine et Données. La couche Domaine contient les Cas d'utilisation et les modèles métier et est complètement isolée d'Android SDK ou d'iOS SDK. Une telle séparation donne 80% des bénéfices pour 20% de l'effort.

// Data layer — responsable uniquement de l'obtention des données
class UserRepository(private val api: UserApi) {
    suspend fun getUser(id: String): User = api.fetchUser(id)
}

// Domain layer — logique métier, ne connaît ni API ni base de données
class GetUserNameUseCase(
    private val repo: UserRepository
) {
    suspend fun invoke(id: String): String {
        val user = repo.getUser(id)
        return "${user.firstName} ${user.lastName}"
    }
}

// UI layer — uniquement l'affichage
class UserViewModel(
    private val getUserName: GetUserNameUseCase
) {
    fun onUserLoaded(id: String) {
        viewModelScope.launch {
            _name.value = getUserName.invoke(id)
        }
    }
}

Le code ci-dessus démontre une séparation pure : UserRepository travaille uniquement avec l'API, GetUserNameUseCase contient la logique métier de formatage du nom, et UserViewModel gère l'état de l'IU. Chaque classe a une raison de changer, ce qui est l'essence de Separation of Concerns.

Avantages et limites de Separation of Concerns

Le principal avantage de SoC est la maintenabilité. Le code divisé en couches indépendantes est plus facile à analyser : le développeur ne regarde que la couche où l'erreur se produit et n'est pas distrait par les autres. Dans les projets à long terme, cela réduit le temps de recherche et de correction des bogues de 30 à 50% par rapport au code monolithique.

Le deuxième avantage important est la testabilité. Lorsque la logique métier est isolée de l'IU et des frameworks, elle est couverte par des tests unitaires sans exécution d'émulateur. Les projets Android et iOS avec une couverture élevée de tests unitaires ont significativement moins de régressions lors de l'ajout de nouvelles fonctionnalités.

La limite principale est l'augmentation de la complexité. La fragmentation excessive en micro-couches et abstractions conduit à ce que pour ajouter un simple bouton, le développeur doive modifier cinq fichiers. Le principe Separation of Concerns nécessite un équilibre raisonnable : ne séparer que les domaines qui changent réellement de manière indépendante. Pour les petits projets, une séparation de base en IU, logique et données sans abstractions supplémentaires est suffisante.