Comment percevez-vous les classes très longues contenant entre 2 000 et 4 000 lignes de code?

Négatif.

Les classes longues violent le principe de responsabilité unique (SRP) et le principe de moindre connaissance (Principle of Least Knowledge). Cela entraîne les problèmes suivants :

• Difficile à lire et à comprendre : Un volume important de code complique la perception de la logique de la classe.
• Difficile à maintenir et à modifier : Modifier une partie de la classe peut affecter involontairement d'autres parties, provoquant des erreurs.
• Risque de duplication de code : La fonctionnalité peut se répéter dans différentes parties de la classe.
• Problèmes avec les tests : Les tests unitaires d'une grande classe deviennent compliqués et fastidieux.
• Réduction de la réutilisation : Il est difficile d'extraire et d'utiliser des parties de la fonctionnalité ailleurs.

Idéalement, les classes doivent être courtes et effectuer une tâche spécifique. La fonctionnalité doit être décomposée en classes ou fonctions plus petites et spécialisées. La refactorisation de ces classes "divines" est une tâche prioritaire pour améliorer la qualité de la base de code.

Pour la décomposition, on peut utiliser les approches suivantes :

• Séparer la logique liée dans des classes indépendantes : Par exemple, gestion des données, logique UI, logique métier.
• Appliquer des patterns de conception : MVC, MVP, MVVM, Repository, Factory, etc.
• Diviser en fonctions/méthodes plus petites : chaque méthode doit faire une chose.
• Utiliser des extensions en Kotlin : pour ajouter des fonctionnalités sans modifier la classe originale.