Que pouvez-vous dire sur l'architecture propre…

L'architecture propre (Clean Architecture), popularisée par Robert Martin ("Oncle Bob"), est un ensemble de principes pour organiser le code, visant à créer un système flexible, testable et facile à maintenir.

Idées principales:

Séparation en couches: Le code est divisé en cercles concentriques, où les cercles internes contiennent la logique métier, et les externes, les détails de mise en œuvre (UI, bases de données, API externes).
Dépendance des couches internes: Les couches externes dépendent des internes, mais pas l'inverse. Cela est réalisé par le principe d'inversion des dépendances.
Encapsulation: Chaque couche cache les détails de sa mise en œuvre des couches externes.
Testabilité: La logique métier, située dans les couches centrales, ne dépend pas des détails externes, ce qui la rend facilement testable en isolation.
Indépendance des frameworks: Les règles principales métier ne sont pas liées à des frameworks spécifiques, UI ou bases de données.

Exemples de couches:

Entités: Contiennent des objets métier et des règles (par exemple, la classe User avec la logique métier liée à l'utilisateur).
Cas d'utilisation (Interactors): Contiennent la logique métier spécifique à l'application (par exemple, GetUserUseCase). Ils orchestrent l'interaction entre les Entités et les Interfaces de Gateway.
Adaptateurs d'interface: Adaptent les données provenant de sources externes à un format compréhensible pour les Cas d'Usage et les Entités (par exemple, Presenters pour UI, Implémentations de Gateway pour bases de données).
Frameworks et pilotes: Couche externe contenant les frameworks (UI, bases de données, services web).

Le principe d'inversion des dépendances joue un rôle clé. Les couches internes définissent des interfaces (Interfaces de Gateway), et les couches externes implémentent ces interfaces. Cela est illustré dans le schéma suivant:

+-----------------+      +-------------------+      +--------------------+      +------------------------+
| Frameworks &    |----->|   Interface       |<-----|    Cas d'Usage     |<-----|        Entités       |
| Pilotes (UI, DB)|      |   Adaptateurs     |      |  (Interactors)     |      |  (Règles métier)     |
+-----------------+      |  (Presentateurs,  |      |                    |      +------------------------+
                         |  Implémentations de Gateway|  |                    |
                         +-------------------+      +--------------------+

Les flèches indiquent la direction des dépendances. Toutes pointent vers l'intérieur, vers la couche des Entités.

Dans le développement Android, la Clean Architecture est souvent mise en œuvre en utilisant des composants tels que:

Couche UI (Présentation): Activity, Fragment, ViewModel, logique UI. Dépend de la couche Domaine.
Couche Domaine (Cas d'Usage): Logique métier de l'application. Ne dépend pas des autres couches.
Couche Données: Sources de données (réseaux, bases de données), dépôts. Implémente des interfaces définies dans la couche Domaine.

Exemple de structure:

racine
├── app
│   ├── src
│   │   └── main
│   │       └── java
│   │           └── com
│   │               └── exemple
│   │                   └── monapp
│   │                       ├── présentation  // Couche UI (ViewModel, Activities, Fragments)
│   │                       │   ├── ui
│   │                       │   └── viewmodel
│   │                       ├── domaine      // Couche de Domaine (Cas d'Usage, Entités, Interfaces)
│   │                       │   ├── entité
│   │                       │   ├── repository  // Interfaces de Domaine
│   │                       │   └── usecase
│   │                       └── données        // Couche de Données (Dépôts, Sources de Données, Mappers)
│   │                           ├── local       // Source de Données Locale (Room)
│   │                           ├── remote      // Source de Données à Distance (Retrofit)
│   │                           ├── mapper
│   │                           └── repository  // Implémentations de Données étendant les Interfaces de Domaine
│   └── build.gradle
└── build.gradle

Avantages:

Testabilité: La logique métier est isolée et facilement testable.
Flexibilité: Facile de remplacer des dépendances externes (par exemple, passer de Room à Realm).
Maintenabilité: La séparation claire des responsabilités rend le code plus facile à comprendre et à maintenir.
Indépendance technologique: La logique métier n'est pas liée à des frameworks ou bibliothèques Android spécifiques.

Inconvénients:

Complexité: Peut être initialement plus difficile à comprendre et à mettre en œuvre, surtout pour de petits projets.
Plus de code: Nécessite d'écrire plus de classes et interfaces comparé à des architectures plus simples.

En général, la Clean Architecture est une approche puissante pour créer des applications Android évolutives et maintenables, surtout pour des projets de complexité moyenne à grande. Elle favorise le développement autour de la logique métier, et non des détails techniques.

Que pouvez-vous dire sur l'architecture propre?