J'ai du mal à voir les avantages du monde réel du code couplé lâche. Pourquoi passer tellement d'efforts à faire quelque chose de flexible pour travailler avec une variété d'autres objets? Si vous savez ce que vous devez réaliser, pourquoi ne pas coder spécifiquement à cette fin?
Pour moi, cela ressemble à la création de variables non typées: cela le rend très flexible, mais s'ouvre à des problèmes car peut-être une valeur inattendue est passée. Cela rend également plus difficile à lire, car vous ne savez pas explicitement ce que être passé.
Pourtant, je me sens comme fortement dactylographié est encouragé, mais un couplage lâchement est mauvais.
Edit: Je sens que mon interprétation d'un couplage lâche est éteinte ou que d'autres la lisent dans le mauvais sens. Un fort couplage pour moi est quand une classe fait référence à une instance concrète d'une autre classe. Le couplage desserré est lorsque une classe fait référence à une interface qu'une autre classe peut mettre en œuvre.
Ma question est alors pourquoi ne pas appeler spécifiquement une instance concrète / définition d'une classe? Je analogue que pour définir spécifiquement le type de variable dont vous avez besoin. Je fais une lecture sur l'injection de dépendance et ils semblent sortir comme un rédaction de la conception de la monnaie.
9 Réponses :
Si vous savez ce que vous devez atteindre, pourquoi ne pas coder spécifiquement à cette fin.
Réponse courte: vous presque jamais savoir exactement ce dont vous avez besoin pour atteindre. Les exigences changent et si votre code est couplé de manière lâche en premier lieu, ce sera moins cauchemar à adapter.
Mais vraiment, n'est-ce pas "Vous ne savez presque jamais exactement ce que vous devez accomplir à la fin"? Comment rendre quelque chose de couplé de manière vague à s'adapter? C'est comme dire: "Cette variable devrait être une chaîne, mais puisque je ne peux pas savoir à coup sûr, mieux la rendre non typée".
Maintenant vous supposez qu'il y a est une fin;)
La réponse est que si vous envisagez fortement typée! = Couplé de manière lâche, vous pensez trop petite à une échelle trop petite pour comprendre pourquoi les couples de manière vague sont bonnes.
Fortement dactylographié est bon car il empêche de trouver des bogues en jetant des erreurs de temps de compilation plutôt que des erreurs de temps d'exécution.
Le code couplé étroitement est mauvais car lorsque vous pensez que vous devez "savoir ce que vous devez accomplir", vous êtes souvent faux, sinon vous ne savez pas encore tout ce que vous devez savoir.
I.e. Vous pourriez ensuite découvrir que quelque chose que vous avez déjà fait pourrait être utilisé dans une autre partie de votre code. Ensuite, peut-être que vous décidez de couper étroitement 2 versions différentes du même code. Ensuite, plus tard, vous devez effectuer une légère modification dans une règle d'entreprise et vous devez modifier 2 ensembles différents de code couplé étroitement, et vous les obtiendrez peut-être que, au mieux, vous aurez au mieux deux fois plus long ... ou au pire Vous allez introduire un bogue en un, mais pas dans l'autre, et cela va non détecté pendant un moment, puis vous vous trouvez dans un vrai cornichon.
Ou peut-être que votre entreprise augmente beaucoup plus vite que prévu et vous devez décharger des composants de la base de données dans un système d'équilibrage de charge, vous devez donc maintenant ré-ingénieur tout ce qui est étroitement couplé au système de base de données existant à utiliser. le nouveau système.
En un mot, le couplage lâche fait pour logiciel beaucoup plus facile à échelle, à maintenir et à s'adapter aux conditions et aux exigences en constante évolution.
Edit: Je sens soit mon interprétation d'un couplage lâche est éteint ou d'autres sont la lire dans le mauvais sens. Fort couplage pour moi est quand une classe références d'une instance concrète de une autre classe. Le couplage lâche est quand une classe fait référence à une interface qui une autre classe peut mettre en œuvre.
Ma question alors est pourquoi ne pas appeler spécifiquement un béton instance / définition d'une classe? je analoguer que pour spécifiquement Définir le type de variable dont vous avez besoin. Je fais une lecture sur Injection de dépendance, et ils semblent sortir comme un fait que lâche coupler une meilleure conception.
Je ne suis pas vraiment sûr de votre confusion ici. Disons par exemple que vous avez une application qui utilise une forte utilisation d'une base de données. Vous avez 100 parties différentes de votre application qui doivent faire des requêtes de base de données. Maintenant, vous pouvez utiliser MySQL ++ dans 100 emplacements différents, ou vous pouvez créer une interface distincte qui appelle MySQL ++ et référencez cette interface dans 100 endroits différents.
Maintenant, votre client dit qu'il souhaite utiliser SQL Server au lieu de MySQL.
Quel scénario pensez-vous que cela va être plus facile à adapter? Réécrivez le code dans 100 endroits différents, ou réécrivez le code en 1 place?
D'accord ... Maintenant, vous dites que peut-être la réécriter dans 100 endroits différents n'est pas si mal.
Alors ... Maintenant, votre client dit qu'il doit utiliser MySQL dans certains endroits et SQL Server dans d'autres emplacements, et Oracle dans d'autres emplacements.
maintenant que faites-vous?
Dans un monde couplé de manière lâche, vous pouvez avoir 3 composants de base de données distincts qui partagent tous la même interface avec différentes implémentations. Dans un monde étroitement couplé, vous auriez 100 séries de relevés de commutation éparpillés avec 3 niveaux de complexité différents.
Peut-être que je suis mal interprété de manière vague couplée. Je vois cela comme "au lieu de référencer directement un objet pour faire une tâche particulière, je vais créer une interface que mon objet peut mettre en œuvre. De cette façon, je peux mettre en œuvre l'interface de quelque manière que ce soit et ne pas être étroitement couplé à celui-ci." Je ne vois pas comment la création d'une interface au lieu d'une référence de classe directe facilite l'adaptation.
STRUT TYPING! = Tapage statique, voir ici .
@Zoul ... Non, Strong Typing! = Typage statique, mais Strong Typing == restrictions de type appliquées par le compilateur.
@Gerald: Votre exemple de DB suppose que vous avez 100 endroits différents où vous répétez votre appel à dB («non couplé» pour l'absence de meilleur terme) ou vous pouvez utiliser une interface (couplée de manière lâche). Il ne parle pas de simplement référencer concrètement une seule classe pour appeler la requête (fortement couplée).
@Gerald: De plus, si je devais utiliser trois DBS différents dans mon code, je préférerais référencer trois classes de DB différentes dans chacune de ces zones. Sinon, je n'aurais aucune idée réelle que DB envisager de voir où mes données étaient écrites - je ne saurais que si elle a été écrite à "une base de données".
@JLX ... Bien sûr que vous le sauriez. La demande ne va pas simplement choisir une implémentation au hasard, vous devez définir quelle implémentation sera utilisée d'une certaine manière; probablement via un fichier de configuration.
@JLX ... Si votre introduction au couplage et à coupler serré consiste à lire sur l'injection de dépendance, je pouvais éventuellement voir la confusion. L'injection de dépendance est sur le côté extrême du couplage en vrac. Les couples lâches et serrés sont des termes relatifs cependant. Lorsque vous êtes «référençant concrètement une seule classe», c'est plus couplé de manière lâche à la cordage d'un tas d'appels de fonction de bases de bas niveau tout au long de votre code. Si cette classe de béton a une interface plus générique qui n'est pas spécifique à sa mise en œuvre interne, c'est-à-dire que vous êtes toujours en désaccord.
@Gerald: Peut-être que c'est là que ma confusion est. J'étais attribuant un couplage lâche uniquement à DI, car j'ai vu des diologies l'utiliser comme un raisonnement principal derrière cette conception.
@JLX ... c'est. Et ce n'est pas une mauvaise prémisse. Suite à l'exemple de la base de données, dans DI, le couplage est souvent aussi lâche que vous pouvez créer de nouvelles implémentations de base de données sans même ré-compiler le reste de l'application. Dans de nombreux cas, vous n'avez même pas besoin d'éteindre l'application, vous pouvez simplement ajouter une nouvelle DLL et effectuer une modification dans un fichier de configuration. Cela peut être surchargé de nombreuses applications et n'est pas nécessairement une bonne idée de design dans tous les cas, mais c'est dans certains. De manière générale, le couplage plus souple, plus les options sont flexibles pour l'adaptation, la mise à l'échelle et la maintenance du code.
Tout d'abord, vous comparez des pommes aux oranges, alors laissez-moi essayer d'expliquer cela de deux perspectives. La frappe fait référence à la manière dont les opérations sur les valeurs / variables sont effectuées et si elles sont autorisées. Le couplage, par opposition à la cohésion, fait référence à l'architecture d'une pièce (ou plusieurs pièces) de logiciels. Les deux ne sont pas directement liés du tout.
Un langage fortement typé est (généralement) une bonne chose parce que le comportement est bien défini. Prenez ces deux exemples, de Wikipedia:
Dactylographie faible : Ce qui précède peut être légèrement déroutant et non -well-défini parce que certaines langues peuvent utiliser l'ASCII (peut-être heex, peut-être des valeurs numériques octal, etc.) pour addition ou une concaténation, il y a donc beaucoup de pièces ouvertes pour des erreurs. En outre, il est difficile de voir si Comme vous pouvez le voir ici, tout est plus explicite, vous savez quelles variables sont plus explicites, vous savez quelles variables sont Et aussi lorsque vous modifiez les types de toutes les variables. Wikipedia dit: L'avantage revendiqué de la typographie faible
est-ce que cela nécessite moins d'effort sur le
partie du programmeur que, parce que
le compilateur ou l'interprète implicitement
effectue certains types de conversions.
Cependant, un désavantage revendiqué est
que des systèmes de programmation faiblement tapés
attraper moins d'erreurs au moment de la compilation et
Certains d'entre eux pourraient encore rester après
les tests ont été complétés. Deux
langages couramment utilisés qui soutiennent
De nombreux types de conversion implicite sont
C et C ++, et il est parfois réclamé
Quelles sont des langues faiblement typées.
Cependant, d'autres soutiennent que ces
Langues Placez suffisamment de restrictions sur
Comment les opérandes de différents types peuvent être
mélangé, que les deux devraient être considérés
comme des langues fortement typées.
Strong VS Type faible, tous deux, ont leurs avantages et leurs inconvénients et non bien ou mauvais. Il est important de comprendre les différences et les similitudes. en informatique, couplage ou
La dépendance est la mesure à laquelle chaque
Le module de programme s'appuie sur chacun de
les autres modules.
Le couplage est généralement contrasté avec
cohésion. Couplage faible souvent
corrélation avec une cohésion élevée et
vice versa. La qualité logicielle
Les mesures de couplage et de cohésion étaient
inventé par Larry Constantine, un
Développeur original de structuré
Design qui était aussi un promoteur précoce
de ces concepts (voir aussi SSADM).
L'accouplement faible est souvent un signe d'un
système informatique bien structuré et a
bon design, et quand combiné avec
Haute cohésion, soutient le général
objectifs de grande lisibilité et
la maintenabilité.
En bref, le faible accouplement est un signe de code très serré, lisible et maintenable. L'accouplement élevé est préféré lorsqu'il s'agit d'API massives ou de grands projets dans lesquels différentes parties interagissent pour former un ensemble. J'espère que j'ai perdu une lumière ici :) a est à l'origine un integer ou a string (ceci peut être important, mais la langue ne se soucie pas vraiment ).
Couplage serré lâche vs
Pourtant, je me sens que comme fortement dactylographié est encouragé, mais un couplage lâchement est mauvais.
Je ne pense pas qu'il soit juste de dire que la frappe forte est bonne ou encouragée. Certes, beaucoup de gens préfèrent des langues fortement typées car il est livré avec une vérification du temps de compilation. Mais beaucoup de gens diraient que la typing faible est bonne. On dirait depuis que vous avez entendu "fort", c'est bien, comment peut "perdre" être bon aussi. Les mérites d'un système de frappe de la langue ne sont même pas dans le domaine d'un concept similaire comme design de classe.
Note latérale: Ne confondez pas la dactylographie ferme et statique
Je suis venu ici après avoir remarqué le terme "faiblement tapé" dans le wiki JavaScript sur le débordement de la pile. Le terme "faiblement tapé" me semble un peu injuste pour moi. Cela fait de manière intrinsèquement un jugement que la typing faible est mauvaise, ce qui est dans certains scénarios. Cela peut être utile dans d'autres. Je pense que le terme "typé de manière lâche" est un peu plus neutre, même si c'est un peu étrange juxtaposé à "fortement typé".
Strong Taping aidera à réduire les erreurs tout en aidant généralement les performances. Plus les outils de génération de code peuvent rassembler des plages de valeurs acceptables pour les variables, plus ces outils peuvent faire pour générer un code rapide.
Lorsqu'il est combiné avec une inférence de type et des caractéristiques telles que des traits (Perl6 et autres) ou des classes de type (HASKELL), le code fortement saisi peut continuer à être compact et élégant.
Si une modification effectuée dans notre fonction, qui se trouve dans une classe dérivée, modifiera le code dans la classe abstraite de base, cela affiche la dépendance totale et cela signifie que ceci est couplé serré.
Si nous n'écrivons pas ou ne recompilons plus le code, alors il montre moins de dépendance, il est donc couplé lâche.
Je pense que le couplage serré / lâche (pour moi: la déclaration d'interface et l'affectation d'une instance d'objet) est liée à la Principe de Lucov . L'utilisation d'un couplage lâche permet certains des avantages du principe de Liskov.
Cependant, dès que l'instanceOf, les opérations de moulage ou de copie sont exécutées, l'utilisation d'un couplage lâche commence à être discutable. De plus, pour les variables locales avec une méthode ou un bloc, elle n'est pas sensée.
Vous avez raison pour que le couplage lâche est presque universellement considéré comme "bon" dans la programmation. Pour comprendre pourquoi, regardons une définition du couplage serré:
Vous dites que a est étroitement couplé à b si a doit changer simplement parce que b modifié. < / p>
C'est une échelle qui va de "complètement découplée" (même si b a disparu, un resterait le même) à "Couplé de manière lâche" (certaines modifications apportées à < em> b pourrait affecter a , mais la plupart des changements évolutifs ne le feraient pas), à "très étroitement couplé" (la plupart des modifications apportées à b affecteraient profondément Un ).
Dans OOP, nous utilisons beaucoup de techniques pour obtenir moins de couplage - par exemple, l'encapsulation aide à découpler le code client des détails internes d'une classe. De plus, si vous dépendez d'une interface, vous n'avez généralement pas à vous inquiéter autant de modifications apportées aux classes concrètes qui implémentent l'interface.
sur une note latérale, vous avez raison que la frappe et le couplage sont liés. En particulier, la typographie plus forte et plus statique a tendance à augmenter le couplage. Par exemple, dans les langues dynamiques, vous pouvez parfois substituer une chaîne pour un tableau, en fonction de la notion qu'une chaîne peut être considérée comme une gamme de caractères. En Java, vous ne pouvez pas, car les tableaux et les chaînes ne sont pas liés. Cela signifie que si B utilisait un tableau et renvoie désormais une chaîne, il est garanti de briser ses clients (juste un exemple simple, mais vous pouvez trouver beaucoup plus qui sont à la fois plus complexes et plus convaincants). Ainsi, la dactylographie plus forte et la dactylographie plus statique sont des compromis. Alors que la dactylographie plus forte est généralement considérée comme bonne, favorisant la saisie statique par rapport à la dynamique est en grande partie une question de contexte et de goûts personnels: essayez de créer un débat entre les programmeurs Python et les programmeurs Java si vous voulez un bon combat.
Alors, nous pouvons revenir à votre question initiale: pourquoi le couplage lâche est-il généralement considéré comme bon? En raison de changements imprévus. Lorsque vous écrivez le système, vous ne pouvez pas éventuellement savoir quelles directions cela évoluera éventuellement dans deux mois ou peut-être deux heures. Cela se produit à la fois parce que les exigences changent au fil du temps et que vous ne comprenez généralement pas le système complètement jusqu'à ce que après vous l'avez écrit. Si tout votre système est très étroitement couplé (une situation qui est parfois appelée «la grande boule de boue»), alors toute modification de chaque partie du système va éventuellement échouir dans toutes les autres parties du système (la définition de «très couplage serré"). Cela crée des systèmes très inflexibles qui se cristallisent éventuellement dans une goutte rigide et sientale. Si vous aviez 100% de foresight au moment où vous commencez à travailler sur un système, vous n'avez pas besoin de découpler.
D'autre part, comme vous obserez, le découplage a un coût car il ajoute de la complexité. Les systèmes plus simples sont plus faciles à changer, de sorte que le défi pour un programmeur est en train de trouver un équilibre entre simple et flexible. Le couplage serré souvent (pas toujours) simplifie un système au coût de la rendre plus rigide. La plupart des développeurs sous-estiment les besoins futurs de changements, de sorte que la heuristique commune est de rendre le système moins couplé que vous êtes tenté de, tant que cela ne le rend pas trop complexe.
(Je sens que je dois ajouter un post scriptum à ceci: un couplage desserré est pas le seul moyen de réduire le coût des changements. Les techniques telles que le développement axé sur les tests ont tendance à donner lieu à des systèmes très simples, et donc relativement peu coûteux de changer, tout en faisant le travail dont ils ont besoin de faire aujourd'hui. Je réponds à l'hypothèse que vous faites des conceptions traditionnelles à l'avance, également appelées "essayer de prédire l'avenir". Une fois que vous passez à Pure TDD, le dilemme simple / flexible devient surtout un point de théâtre.)
"Tant que cela ne le rend pas trop complexe" est la chose essentielle à garder à l'esprit. Comment savez-vous quand une conception est trop complexe? Dans mon expérience, l'expérience est le meilleur guide :)
La question est juste de souligner que la typing faible / dynamique est en effet une extension logique du concept de couplage lâche, et il est incompatible pour les programmeurs de favoriser une autre chose.
Le couplage lâche est devenu quelque chose d'un mot à la mode, avec De nombreux programmeurs mettent en œuvre inutilement les interfaces et les modèles d'injection de dépendance - ou, plus souvent, leurs propres versions brouillées de ces modèles - sur la base de la possibilité d'un changement futur amorphe des exigences. Il n'y a pas de cacher le fait que cela introduit une complexité supplémentaire et rend le code moins maintenu pour les futurs développeurs. Le seul avantage est que ce couplage anticipant des lâches accumule une modification future des exigences plus facile à mettre en œuvre ou de promouvoir la réutilisation du code. Cependant, souvent, les changements d'exigences impliquent suffisamment de couches du système, de l'interface utilisateur au stockage, que l'accouplement lâche n'améliore pas du tout la robustesse de la conception et rend certains types de changements triviaux plus fastidieux.
On n'est pas concerné par l'autre du tout. . .
Je ne vote pas pour fermer cette question, mais imo vous dirigez très près de la ligne "argumentative" ici; Surtout parce que vous avez déjà déclaré que vous savez exactement pourquoi le code devrait être couplé de manière lâche ... mais vous êtes simplement en désaccord.
Je suis en désaccord parce que je sens que le concept est "le rendre flexible parce que vous ne savez pas ce dont vous avez besoin", mais ce n'est pas la façon dont la typographie varie est vue.
@JLX ... La modification du code pour travailler avec de nouveaux types de variable est généralement assez facile. Ré-ingénierie des gros sandes de code parce que vous devez modifier la façon dont un algorithme particulier fonctionne ... pas tellement.
Dire le code doit être suffisamment couplé, c'est comme dire que les voitures doivent courir sur le gaz. Mais lo 'et voici, certaines voitures courent sur le diesel. Zomg. Ce sont des voitures mauvaises! Mauvais je dis !!
Une voiture couplée lâche pourrait plus facilement fonctionner sur le gaz ou le diesel;)