web-dev-qa-db-fra.com

optimisation de la forte cohésion et du couplage lâche

J'ai été interrogé dans un entretien technique sur la cohésion et le couplage d'un projet. J'ai longuement expliqué leurs définitions, bien que je n'aie pas répondu correctement à la deuxième partie de la question, comme il l'a dit.

"Comment pouvons-nous réaliser simultanément une conception hautement cohésive et faiblement couplée dans un projet et expliquer, s'il vous plaît, comment cette approche devrait-elle être mise en œuvre dans un projet monolithique?"

J'ai répondu que ces deux objectifs sont contradictoires, nous devons donc trouver le meilleur pari pour chaque projet ou module, mais je ne pouvais pas fournir de réponse complète. 

J'apprécierais si quelqu'un m'aide. 

javaooploose-couplingcohesion
7
akarimin

Je voudrais commencer par répondre en disant que cela est tout à fait opposé à ce que vous avez décrit comme "les deux définitions sont contradictoires". Je vais décrire en apportant une citation de John W. Satzinger, Analyse et conception de systèmes dans un monde en mutation, faits marquants book

Un faible couplage est souvent lié à une cohésion élevée et inversement

En disant dans un Monolithic , ils vous signalaient de poser des questions sur les SOLID principes que si vous les appliquez, vous obtiendrez un projet de cohésion élevée et de couplage faible.

Voici les définitions:

1. Principe de responsabilité unique (SRP)

Définition: Il ne devrait jamais y avoir plus d'une raison pour qu'une classe change.

Avantages:

  • cohésion plus forte dans la classe 
  • couplage plus lâche entre les classes de dépendance, 
  • meilleure lisibilité
  • code moins complexe
  • Code plus facile à comprendre et à maintenir.

2. Principe ouvert-fermé (OCP)

Définition: Les entités logicielles (classes, modules, fonctions, etc.) doivent être ouvertes pour extension, mais fermées pour modification.

Avantages:  

  • couplage lâche, 
  • améliorer la lisibilité 
  • réduire le risque de rupture des fonctionnalités existantes
  • Code maintenable et réutilisable.
  • Code plus robuste.

3. Principe de substitution de Liskov (LSP)

Définition: Les objets d'un programme doivent pouvoir être remplacés par des occurrences de leurs sous-types sans altérer l'exactitude de ce programme.

Avantages:  

  • couplage lâche
  • Code plus réutilisable.
  • Les hiérarchies de classes sont faciles à comprendre.

4. Principe de séparation des interfaces (ISP)

Définition: de nombreuses interfaces spécifiques au client valent mieux qu'une interface générique

Avantages:  

  • Système découplé.
  • Code facile à refactoriser.

5. Principe d'inversion de dépendance (DIP)

Définition: Les modules de haut niveau ne doivent pas dépendre de modules de bas niveau, mais doivent tous deux dépendre de l'abstraction. L'abstraction ne devrait pas dépendre des détails; les détails devraient plutôt dépendre de l'abstraction.

Avantages:  

  • haute cohésion.
  • Réduisez le couplage.
  • Code plus réutilisable.

Plus d'informations

Livres

  • Steve McConnell's Code Complete
  • Code propre de l'oncle Bob
8
MohammadReza Alagheband

Selon Wikipedia ( https://en.wikipedia.org/wiki/Cohesion_(computer_science) ) 

Une cohésion élevée est souvent en corrélation avec un couplage lâche, et inversement

L’objectif est donc d’obtenir une forte cohésion et couplage lâche. Pour y parvenir, vous devez développer des classes ne faisant qu'une chose, diviser le projet monolithique en plusieurs modules (DAO, interface utilisateur, logique métier) et programmer en une interface de sorte que les autres classes (ou autres modules) ne le sachent pas. rien sur les composants internes d’autres classes/modules et ne connaître que les contrats externes (interfaces/API).

1
Ivan

Je ne connaissais pas le concept de cohésion avant de lire votre question. De Wikipedia ( ici ):

Les modules à forte cohésion tendent à être préférables, car une forte Est associée à plusieurs caractéristiques souhaitables du logiciel , Notamment la robustesse, la fiabilité, la réutilisabilité et la compréhensibilité. En revanche, une faible cohésion. est associé à des caractéristiques indésirables telles que comme difficiles à maintenir, à tester, à réutiliser ou même à comprendre.

La cohésion contraste souvent avec le couplage, un concept différent. Une cohésion élevée Est souvent corrélée à un couplage lâche, et inversement.

Je pense que vous voulez une forte cohésion au sein de chaque module et un couplage lâche entre eux, ce qui peut être obtenu en ne permettant aux modules de communiquer que par le biais d'interfaces abstraites simples. Pour définir ces interfaces, vous devez concevoir une séparation claire des problèmes, dans laquelle toutes les tâches étroitement liées sont effectuées dans la même classe, tandis que les tâches de granularité différente (par exemple, algorithme de haut niveau par rapport aux détails d'implémentation de bas niveau) sont séparées et abstrait par des interfaces.

1
Dici