Cohésion dans le développement mobile : bases, niveaux et comment l'améliorer

Qu'est-ce que la cohésion

La cohésion est une métrique qui évalue à quel point les méthodes, champs et propriétés d'une classe ou d'un module sont logiquement connectés. Un module hautement cohésif effectue une seule tâche et ne contient que les éléments nécessaires pour l'accomplir. Un module à faible cohésion essaie de faire plusieurs choses à la fois — ses méthodes sont faiblement liées en termes de sens.

Dans le contexte de la programmation orientée objet, la cohésion est étroitement liée au Principe de Responsabilité Unique (S). Si une classe a une responsabilité claire, sa cohésion est généralement élevée. Si une classe gère à la fois l'interface utilisateur, la logique métier et le réseau — la cohésion est faible, et cette classe doit être divisée en plusieurs classes distinctes avec des responsabilités plus ciblées.

Comprendre la cohésion aide les développeurs à prendre des décisions de refactoring. Lorsque vous voyez une méthode dans une classe qui n'utilise aucun champ de la classe, c'est un signe de faible cohésion. Cette méthode est soit mal placée dans la classe, soit la classe est mal conçue. Rechercher une cohésion élevée est un effort continu pour améliorer l'architecture à tous les niveaux du code.

Types et niveaux de cohésion

En génie logiciel, on distingue sept niveaux de cohésion, classés du pire au meilleur. Comprendre cette échelle permet d'évaluer objectivement la qualité d'un module et de déterminer la direction du refactoring. Plus le niveau est élevé, plus le code sera maintenable et compréhensible.

Cohésion faible : accidentelle, logique et temporelle

Accidentelle — le pire niveau, où les éléments d'un module sont regroupés aléatoirement sans aucune connexion logique. Exemple : une classe Utilities avec des méthodes de formatage de dates, d'envoi d'e-mails et de calcul de remises. Une telle classe ne peut être comprise sans lire toutes ses méthodes, et modifier une méthode pourrait en casser d'autres simplement parce qu'elles sont ensemble.

Logique — les éléments effectuent des tâches logiquement liées mais fondamentalement différentes. Une classe avec les méthodes parseJSON, parseXML et parseCSV est logiquement connectée par le sujet de l'« analyse », mais chaque méthode fait un travail radicalement différent. Le problème : lorsqu'un nouveau format (YAML) est ajouté, la classe grossit et son interface gonfle.

Temporelle — les éléments sont regroupés par temps d'exécution. Une classe AppInitializer qui configure la base de données, charge la configuration et initialise les analyses — tout cela se produit au démarrage de l'application, mais les tâches elles-mêmes ne sont pas liées. Il est préférable de les diviser en Initializers séparés pour chaque domaine de responsabilité.

Cohésion moyenne : procédurale et communicationnelle

Procédurale — se produit lorsque les éléments sont unis par une séquence d'exécution. Un module « Traitement de commande » contient les méthodes validateCart, processPayment et sendConfirmation — chaque méthode est appelée strictement après la précédente. C'est mieux que la cohésion accidentelle ou logique, mais ce n'est pas encore idéal : chaque étape pourrait être extraite dans un module séparé.

Communicationnelle — les éléments travaillent avec les mêmes données. Une classe UserService avec les méthodes getUser, updateUser et deleteUser est unie par l'entité commune User. C'est significativement mieux que la cohésion procédurale : la classe a un domaine clair. La plupart des classes Repository dans les projets mobiles ont une cohésion communicationnelle.

Cohésion élevée : fonctionnelle

Fonctionnelle — le niveau le plus élevé, où chaque élément du module participe à l'exécution d'une seule tâche. Une classe PasswordValidator avec une seule méthode validate qui vérifie la longueur, la présence de caractères et la complexité du mot de passe est un exemple de cohésion fonctionnelle. Si une telle classe change, c'est uniquement parce que les règles de validation du mot de passe ont changé.

Atteindre la cohésion fonctionnelle est l'objectif principal du refactoring architectural. Chaque classe doit avoir exactement une raison de changer. Dans le développement mobile, la cohésion fonctionnelle est obtenue en extrayant des Use Cases séparés, des vues personnalisées, des formateurs et des validateurs. Chacune de ces classes est un bloc de construction complet avec un domaine de responsabilité clair.

Cohésion vs Couplage

Cohésion et couplage sont les deux faces d'une même qualité. Plus la cohésion au sein d'un module est élevée, plus le couplage entre modules tend à être faible. Un système bien conçu recherche simultanément une cohésion interne élevée et un couplage externe faible. Ce principe est reconnu comme fondamental en génie logiciel depuis les années 1970.

La relation cohésion-couplage peut être considérée comme un équilibre. Si un développeur sacrifie la cohésion en combinant plusieurs tâches dans une classe, les modules voisins gagnent plus de dépendances — ils doivent accéder à cette classe surchargée pour différents objectifs, ce qui augmente le couplage. À l'inverse, diviser en petites classes hautement cohésives réduit les points d'interaction entre les modules.

En pratique, cela signifie : lorsque vous extrayez une nouvelle classe avec une cohésion fonctionnelle, vous libérez simultanément les autres modules de la nécessité de connaître les détails de son implémentation. Par exemple, extraire EncryptionManager dans une classe séparée avec une cohésion fonctionnelle donne aux autres modules une interface simple encrypt/decrypt sans qu'ils aient besoin de comprendre les détails de l'algorithme de chiffrement.

// Faible cohésion — la classe fait tout à la fois
class UserManager {
    fun fetchAndSaveUser(id: String) { }
    fun parseUserJson(json: String): User { }
    fun displayUserName(user: User): String { }
    fun validateEmail(email: String): Boolean { }
}

// Cohésion élevée — chaque classe résout une tâche
class UserRepository {
    fun fetchUser(id: String): User { }
}

class UserJsonParser {
    fun parse(json: String): User { }
}

class UserNameFormatter {
    fun format(user: User): String { }
}

class EmailValidator {
    fun isValid(email: String): Boolean { }
}

L'exemple montre la différence : UserManager a une cohésion logique — toutes les méthodes concernent les utilisateurs, mais chacune fait un travail fondamentalement différent. Après le refactoring, chaque classe a une cohésion fonctionnelle et le couplage est réduit car les autres modules dépendent uniquement de la classe dont ils ont besoin, et non de tout UserManager.

Comment mesurer la cohésion dans le code

LCOM (Manque de Cohésion des Méthodes) est la métrique la plus connue pour mesurer la cohésion d'une classe. LCOM compte combien de paires de méthodes ne partagent pas de champs communs. Une valeur de 0 signifie une cohésion idéale (toutes les méthodes travaillent avec les mêmes champs), tandis qu'une valeur élevée indique une faible cohésion. LCOM4 (une version améliorée) prend en compte les connexions transitives via d'autres méthodes.

Dans le développement Android, les métriques de cohésion peuvent être obtenues via Detekt avec la règle TooManyFunctions. Les classes avec des dizaines de méthodes utilisant différents groupes de champs ont probablement une faible cohésion. Sous iOS, SwiftLint a les règles file_length et function_body_length — des indicateurs indirects : les fichiers et méthodes longs signalent souvent une faible cohésion.

Une méthode d'évaluation manuelle : posez la question « Cette classe changera-t-elle pour une raison ou pour plusieurs raisons ? » Si vous pouvez nommer plus d'une raison indépendante — la classe a une faible cohésion. Un deuxième test : « Cette classe peut-elle être divisée en deux classes indépendantes ? » Si oui — faites-le. Vérifier régulièrement la cohésion lors des revues de code prévient les classes God et réduit la dette technique.

Comment améliorer la cohésion dans un projet mobile

La première étape — appliquer le Principe de Responsabilité Unique. Chaque classe doit avoir une responsabilité claire. Si une classe a une méthode qui ne se rapporte pas à sa tâche principale, extrayez-la dans une classe séparée. La technique Extract Class ou Extract Delegate dans les IDE automatise ce processus. Après l'extraction, vérifiez si la classe originale est devenue plus ciblée.

La deuxième étape — utiliser le pattern Façade pour simplifier l'interface. Si une classe fournit 20 méthodes mais que les clients n'en utilisent que 3–4, la classe peut avoir une faible cohésion — elle offre trop de fonctionnalités diverses. Groupez les méthodes par sujet, extrayez des classes séparées pour chaque groupe, et faites de la classe originale une façade ou supprimez-la.

La troisième étape — prêter attention aux groupes de champs. Si une classe a des champs qui ne sont utilisés que par un sous-ensemble de méthodes — c'est un indicateur de faible cohésion. Divisez la classe par groupes de champs. Par exemple, si une classe contient les champs userRepository, networkClient et analyticsTracker, mais que le premier groupe de méthodes utilise uniquement userRepository tandis que le second utilise networkClient — ce sont deux classes différentes.

La quatrième étape — éviter de créer des classes « utilitaire » avec des méthodes static arbitraires. Chaque méthode static dans une classe Utils ou Helpers est candidate à l'extraction dans une classe spécialisée. FormatUtils.dateToString est mieux placé dans DateFormatter, et ValidationUtils.isValidEmail dans EmailValidator. Cela augmente la cohésion de chaque classe et rend le code auto-documenté.