Architecture et Patterns dans le Développement Mobile : Définition, Types et Application

Principaux Patterns d'Architecture

Un pattern d'architecture détermine comment les responsabilités sont réparties entre les classes de l'application. Le choix du pattern affecte la facilité d'ajout de nouveaux écrans et de test du code.

MVC (Model-View-Controller)

MVC est un pattern classique où Model gère les données, View l'affichage et Controller la logique. Sous iOS, MVC est le modèle par défaut (UIViewController) ; sous Android, Activity. L'inconvénient est que le Controller devient souvent « massif » (Massive View Controller). Selon une enquête auprès des développeurs iOS (Reddit, 2025), 62% citent MVC comme la principale cause de code illisible dans les projets hérités.

MVP (Model-View-Presenter)

MVP se différencie par le fait que le Presenter gère la View via une interface, améliorant la testabilité. MVP était populaire sur Android avant Jetpack, mais reste moins pratique que MVVM.

MVVM (Model-View-ViewModel)

MVVM est le pattern recommandé par Google pour Android et par Apple pour iOS. Le ViewModel stocke l'état, et la View s'abonne aux changements via Data Binding ou @Published. Le ViewModel ne dépend pas de la View et est facile à tester. Chez IT Sectr, nous utilisons MVVM comme pattern principal dans tous nos projets.

MVI et VIPER

MVI est un pattern réactif où chaque action suit le cycle Intent → Model → View. MVI garantit un état prévisible. VIPER est un pattern iOS avec cinq couches (View, Interactor, Presenter, Entity, Router), offrant un isolement maximal mais nécessitant beaucoup de code standard.

Clean Architecture

Clean Architecture est le concept de Robert Martin qui divise une application en couches : les couches externes (UI, BD, réseau) dépendent des couches internes (logique métier, entités). Dans le développement mobile, Clean Architecture comprend trois couches : data (référentiels), domain (Use Cases) et presentation (ViewModels, UI).

Repository Pattern est un composant clé de Clean Architecture, abstraisant la source de données. Le référentiel décide s'il faut récupérer les données du réseau ou du stockage local (Room, Core Data) et renvoie un format unifié. Selon Google (Architecture Guide, 2025), Repository Pattern est recommandé pour toute application avec des requêtes réseau. Clean Architecture se justifie dans les projets de 3 à 5 écrans ou plus — pour les applications simples, commencez par MVVM.

Patterns de Création

Singleton

Singleton est un pattern d'architecture qui garantit une instance unique d'une classe et fournit un point d'accès global à celle-ci. Il est utilisé pour les bases de données, les gestionnaires de paramètres et les caches. En Kotlin, il est créé via object. L'inconvénient est qu'il complique les tests en raison de l'état global.

Factory et Builder

Factory délègue la création d'objets à une méthode d'usine — au lieu de new, vous appelez l'usine. Builder est un pattern de construction étape par étape pour les objets complexes avec de nombreux paramètres (AlertDialog.Builder, NotificationCompat.Builder). Builder améliore la lisibilité et permet aux objets de rester immuables après l'assemblage.

Patterns Structurels et Comportementaux

Adapter, Facade, Delegate, Protocol

Adapter est un pattern d'architecture qui convertit l'interface d'une classe en une interface attendue par le client. Sous Android, c'est RecyclerView.Adapter. Facade fournit une interface simplifiée à un système complexe — par exemple, une façade pour une API qui masque les détails d'authentification. Delegate est un pattern iOS où un objet délègue une tâche (UITableViewDelegate). Protocol est l'équivalent d'une interface en Swift.

Observer et Strategy

Observer est un pattern d'abonnement aux changements : le sujet notifie les abonnés des mises à jour. Dans le développement mobile, Observer est le fondement de LiveData, StateFlow, RxJava et Combine. Strategy est un pattern d'algorithmes interchangeables : vous branchez une stratégie différente (tri, validation) sans multiples instructions if-else.

Injection de Dépendances et Gestion d'État

Dependency Injection est un pattern d'architecture où un objet reçoit ses dépendances de l'extérieur au lieu de les créer lui-même. Au lieu de new Database(), vous passez la base de données via le constructeur. DI simplifie les tests — vous pouvez utiliser un Mock à la place d'une base de données réelle — et facilite l'échange d'implémentations. Frameworks DI populaires : Dagger et Hilt (Android), Swinject (iOS), Koin (Kotlin). Hilt — un wrapper autour de Dagger recommandé par Google — réduit la configuration DI de 3 fois.

Service Locator est une alternative à DI avec un registre central de dépendances. Plus simple à implémenter, mais il cache les dépendances de la classe, rendant les tests plus difficiles. Les projets modernes préfèrent DI via Hilt ou Koin.

Gestion d'État dans Flutter

Dans Flutter, la gestion d'état est un écosystème à part entière. Redux — un Store unique avec des changements via Actions → Reducer → State. BLoC de Google sépare les événements et les états via Stream. Provider — un conteneur DI simple recommandé par Google pour Flutter jusqu'en 2023. Riverpod — un Provider amélioré qui résout les problèmes de compilation et de test. GetX — un micro-framework avec routage, DI et gestion d'état. Pour les développeurs Flutter débutants, nous recommandons Provider ou Riverpod comme les solutions les mieux documentées.

Principes SOLID et DRY

Au-delà des patterns spécifiques, il existe des principes généraux de conception d'architecture applicables dans tout langage et framework.

SOLID — cinq principes de conception orientée objet : Single Responsibility (une classe — une tâche), Open-Closed (ouvert à l'extension, fermé à la modification), Liskov Substitution (les sous-classes remplacent la classe parente), Interface Segregation (petites interfaces), Dependency Inversion (dépendre des abstractions). Dans le développement mobile, SRP est le principe le plus utile : chaque classe ne fait qu'une seule chose. Selon l'expérience d'IT Sectr, la violation de SRP est la cause de 70% des problèmes de test dans les projets commerciaux.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

L'exemple Kotlin montre comment nous transformons une classe UserManager avec quatre responsabilités en quatre classes avec une responsabilité chacune. Ce code est plus facile à tester, modifier et réutiliser.

DRY (Don't Repeat Yourself) — évitez la duplication de code. Extrayez la logique répétée dans des méthodes ou classes partagées. KISS (Keep It Simple, Stupid) — la simplicité est plus importante que l'élégance. YAGNI (You Aren't Gonna Need It) — n'écrivez pas de code pour quelque chose qui pourrait ne pas être nécessaire. Ces principes aident à écrire un code propre et maintenable sans redondance.

Patterns de la Plateforme Android

ViewModel (Android) est un composant d'architecture Jetpack pour stocker l'état de l'UI, résistant à la rotation de l'écran. ViewModel ne contient pas de références à Activity et est automatiquement nettoyé. LiveData — un conteneur de données observable avec connaissance du cycle de vie. StateFlow — un remplacement moderne de LiveData basé sur Kotlin Flow. SharedFlow — un Hot Flow pour les événements uniques (navigation, toasts).

Data Binding et Two-Way Binding — mécanismes de liaison entre l'UI et les données sous Android. Data Binding déclare la connexion en XML ; Two-Way Binding met automatiquement à jour le champ dans le ViewModel. Unidirectional Data Flow — un principe où les données circulent dans une seule direction : State → UI → Event → State. Chez IT Sectr, nous utilisons Unidirectional Data Flow dans tous les nouveaux projets — cela réduit le nombre de bugs causés par des changements d'état inattendus.