Quelle est la signification de ' haute cohésion '?

Une façon de voir la cohésion en termes dOO est de savoir si les méthodes la classe utilise lun des attributs privés. En utilisant des métriques telles que LCOM4 (Manque de méthodes cohésives), comme indiqué par gnat dans cette réponse ici , vous pouvez identifier les classes qui pourraient être refactorisées. La raison pour laquelle vous souhaitez refactoriser des méthodes ou des classes pour être plus cohérentes est que simplifie la conception du code pour que dautres lutilisent . Croyez-moi; la plupart des responsables techniques et des programmeurs de maintenance vous aimeront lorsque vous résolvez ces problèmes.

Vous pouvez utiliser des outils dans votre processus de construction tels que Sonar pour identifier une faible cohésion dans la base de code. Il y a quelques cas très courants auxquels je peux penser où les méthodes sont faibles en « cohésion » :

Cas 1: la méthode nest pas du tout liée à la classe

Prenons lexemple suivant:

 public class Food { private int _foodValue = 10; public void Eat() { _foodValue -= 1; } public void Replenish() { _foodValue += 1; } public void Discharge() { Console.WriteLine("Nnngghhh!"); } }  

Une des méthodes , Discharge(), manque de cohésion car cela ne touche aucun des membres privés de la classe. Dans ce cas, il ny a quun seul membre privé: _foodValue. Si elle ne fait rien avec les éléments internes de la classe, alors y at-elle vraiment sa place? La méthode pourrait être déplacée vers une autre classe qui pourrait être nommée par exemple FoodDischarger.

 // Non-cohesive function extracted to another class, which can // be potentially reused in other contexts public FoodDischarger { public void Discharge() { Console.WriteLine("Nnngghhh!"); } }  

Dans vous « le faites en Javascript, puisque les fonctions sont des objets de première classe, la décharge peut être une fonction gratuite:

 function Food() { this._foodValue = 10; } Food.prototype.eat = function() { this._foodValue -= 1; }; Food.prototype.replenish = function() { this._foodValue += 1; }; // This Food.prototype.discharge = function() { console.log("Nnngghhh!"); }; // can easily be refactored to: var discharge = function() { console.log("Nnngghhh!"); }; // making it easily reusable without creating a class  

Cas 2: classe utilitaire

Cest en fait un cas courant qui brise la cohésion. Tout le monde aime les classes utilitaires, mais celles-ci indiquent généralement des défauts de conception et la plupart du temps rendent la base de code plus difficile à maintenir (en raison de la forte dépendance associée aux classes utilitaires). Considérez les classes suivantes:

 public class Food { public int FoodValue { get; set; } } public static class FoodHelper { public static void EatFood(Food food) { food.FoodValue -= 1; } public static void ReplenishFood(Food food) { food.FoodValue += 1; } }  

Ici, nous pouvons voir que la classe utilitaire a besoin pour accéder à une propriété de la classe Food. Les méthodes de la classe utilitaire nont aucune cohésion dans ce cas car elles ont besoin de ressources extérieures pour faire leur travail. Dans ce cas, il ne serait pas préférable davoir les méthodes dans la classe avec laquelle elles « travaillent avec elle-même ( un peu comme dans le premier cas)?

Cas 2b: Objets cachés dans les classes utilitaires

Il y a un autre cas de classes utilitaires où il y a des objets de domaine non réalisés. La première réaction instinctive un programmeur a quand la manipulation de chaînes de programmation est décrire une classe utilitaire pour elle.Comme celui ici qui valide quelques représentations de chaîne courantes:

 public static class StringUtils { public static bool ValidateZipCode(string zipcode) { // validation logic } public static bool ValidatePhoneNumber(string phoneNumber) { // validation logic } }  

Quoi la plupart ne réalisent pas ici quun code postal, un numéro de téléphone ou toute autre représentation sous forme de chaîne peut être un objet lui-même:

 public class ZipCode { private string _zipCode; public bool Validates() { // validation logic for _zipCode } } public class PhoneNumber { private string _phoneNumber; public bool Validates() { // validation logic for _phoneNumber } }  

La notion selon laquelle vous ne devriez pas » t « manipuler les chaînes » directement est détaillée dans cet article de blog par @codemonkeyism , mais est étroitement liée à la cohésion parce que la façon dont les programmeurs utilisent les chaînes en mettant la logique dans les classes utilitaires.

Commentaires

• Maintenant, si seulement nous pouvions obtenir nos ORM pour gérer correctement nos classes ZipCode et PhoneNumber personnalisées: |
• +1 bons exemples. Pour le dernier point, voir aussi sourcemaking.com/refactoring/primitive-obsession
• @Pete Votre ORM le gérera si vous fournissez une conversion opérateurs de la chaîne au type défini (ZipCode, PhoneNumber): msdn.microsoft.com/en-us/library/85w54y0a.aspx

Une cohésion élevée signifie garder ensemble des éléments similaires et connexes, coupler ou fusionner des parties qui partagent du contenu, des fonctionnalités, raison ou objectif . En dautres termes, une faible cohésion pourrait par exemple signifier une fonction / classe / entité de code qui sert à plusieurs fins plutôt que dêtre «  au point « . Lune des idées porteuses est de faire une chose et bien la faire . Dautres pourraient inclure le fait évident que vous ne répliquez pas des fonctionnalités similaires dans de nombreux endroits. Cela améliore également la localité de la base de code, certains types de choses se trouvent à un certain endroit (fichier, classe, ensemble de fonctions, …) plutôt que dêtre dispersée.

À titre dexemple, considérons une classe qui sert à deux ou trois objectifs: charge / stocke des ressources (par exemple un fichier) puis analyse et affiche le Une telle classe a une cohésion faible car elle gère au moins deux tâches distinctes qui ne sont pas du tout liées (E / S de fichiers, analyse et affichage). Une conception à haute cohésion pourrait utiliser des classes distinctes pour charger et stocker la ressource, lanalyser puis lafficher.

Dun autre côté, un couplage faible vise à garder les choses distinctes séparées – afin quelles interagissent les unes avec les autres le moins possible, ce qui réduit la complexité et simplifie la conception.

Cela signifie que les parties dun objet sont étroitement liées à la fonction de lobjet. Cela signifie quil y a très peu ou pas de déchets dans lobjet en termes de fonction ou de responsabilité. Cela peut à son tour améliorer la compréhension de lutilisation de lobjet en question.

Commentaires

• doesn ' Cela sapplique-t-il également à un niveau supérieur à celui des objets? ex. regrouper des objets / fonctions liés à une tâche dans des espaces de noms?