Quelle conception prend en charge le couplage faible?

Design #1 Quelle conception prend en charge le couplage faible?

Design #2

qui prend en charge la conception de couplage global faible? et pourquoi?

2011-04-20 user478636

Le second concentre tous les "smarts" dans le registre, ce qui semble bien. Puis Paiement et Vente "faites ce qu'on leur dit". Dans le premier cas, la responsabilité est plus répartie, et peut-être plus délicate. Mais ... vous ne savez pas exactement comment vous mesurez le faible couplage global! Je serai intéressé de voir les réponses à venir, aussi. :-) –

Je pense que vous pouvez trouver un livre ([voir en ligne] (http://books.google.co.uk/books?id=9CL446IzhuAC&pg=PA38&lpg=PA38&dq=events+chapter+one+coupling&source=bl&ots = qmJTOuCz90 & sig = EZKvZBjF8QmGohatC97HsmAqG0c & hl = fr & ei = wj6tTqe5LcTX8gON_YyiCw & sa = X & oi = book_result & ct = résultat & resnum = 6 & ved = 0CEMQ6AEwBQ # v = OnePage & q = événements% 20chapter% 20one% 20coupling & f = false)) "programmation basée sur les événements: prendre des événements à la limite " ne pas Prenons le titre à sa juste valeur - Le premier chapitre donne une description perspicace et une méthode permettant de réduire/décaler le couplage vers des formes de comportement couplées de moindre importance. –

Dans le premier paiement est couplé à la vente. Dans le second est couplé à Register and Sale. Je dirais que le premier a un couplage inférieur parce que Register n'a aucun concept de paiement. Le paiement pourrait complètement être éliminé complètement et ne nécessiterait aucun changement à Register. Dans la seconde si vous avez éliminé le paiement, le registre et la vente devront être modifiés.

Source

2011-04-20 18:19:18 nsfyn55

Du point de vue du créateur, un registre enregistre le paiement. Donc, il contaisn des informations sur le paiement.Donc, par définition, il devrait créer un paiement non? – user478636

Ce n'est pas pertinent. Si vous avez supprimé tous les registres, paiements et ventes, remplacez-les par Object1, Object2 et Object3. Je dirais que l'un est le plus découplé. Dessinez un graphique de dépendance simple et comptez les lignes. Way 2 - Inscription dépend de la vente et du paiement. La vente dépend du paiement -> c'est 3 lignes. Way 1 - Register dépend de la vente, la vente dépend du paiement -> 2. 2 est inférieur à 3, donc il y a moins de couplage – nsfyn55

"En informatique, le couplage ou la dépendance est le degré auquel chaque module de programme s'appuie sur chacun des les autres modules. " – nsfyn55

Dans le premier Payment est créé par Sale donc c'est plus couplé.

dans une seconde est faible couplage avec l'injection de dépendance - http://en.wikipedia.org/wiki/Dependency_injection, sorcière est un motif de conception qui sépare le comportement de la résolution des dépendances, ainsi découplage composants hautement dépendantes. Payment et Sale étaient fortement dépendants dans la première image.

Source

2011-04-20 18:06:29 dantuch

Je ne suis pas sûr d'être d'accord avec cela (pour des raisons évidentes :)). DI ou pas DI ne rend pas le design plus ou moins couplé. Dans ce cas, l'une de ces classes doit instancier le paiement à la volée. Même si vous utilisez DI il serait couplage inférieur pour encapsuler entièrement le paiement au sein de la vente. Il semblerait qu'un design plus sensé serait d'enregistrer RegisterPayment (p) et de créer une vente, mais ce n'est pas mon registre – nsfyn55

@ nsfyn55 vous dites DI doesn 't (faire le design plus ou moins couplé) :) Je dis qu'il fait - avec DI Paymant peut être réutilisé ... il peut même avoir une instance;) – dantuch

Je ne vois pas le point dans le premier exemple. S'inscrire n'est pas nécessaire?

Dans le deuxième exemple, tout type de paiement peut être utilisé. (Visa, argent liquide, etc.) D'où il est plus vaguement couplé.

Source

2011-04-20 18:51:54 jgauffin

Quelle conception prend en charge le couplage faible?

Répondre

Questions connexes