5

Design #1

Design #2

Which Design supports overall low coupling? and why?

user478636
  • 3,304
  • 15
  • 49
  • 76
  • The second one focuses all the "smarts" in register, which seems nice. THen Payment and Sale just "do what they're told". In the first case, the responsibility is more distributed, and maybe trickier. But... not sure how you actually measure overall low coupling! I'll be interested to see the upcoming answers, too. :-) – david van brink Apr 20 '11 at 18:10
  • I think that you may find a book ([view it online](http://books.google.co.uk/books?id=9CL446IzhuAC&pg=PA38&lpg=PA38&dq=events+chapter+one+coupling&source=bl&ots=qmJTOuCz90&sig=EZKvZBjF8QmGohatC97HsmAqG0c&hl=en&ei=wj6tTqe5LcTX8gON_YyiCw&sa=X&oi=book_result&ct=result&resnum=6&ved=0CEMQ6AEwBQ#v=onepage&q=events%20chapter%20one%20coupling&f=false)) "Event-based programming: taking events to the limit " Don't take the title at face value - Chapter One gives an insightful description and method by which to reduce/shift coupling to lesser forms of coupled behavior. – Paul Sullivan Oct 30 '11 at 12:23

3 Answers3

1

In first one Payment is created by Sale so this is more coupled.

in second one there is low coupling with dependency injection - http://en.wikipedia.org/wiki/Dependency_injection , witch is a design pattern that separates behavior from dependency resolution, thus decoupling highly dependent components. Payment and Sale were highly dependent in first picture.

dantuch
  • 9,123
  • 6
  • 45
  • 68
  • 1
    I'm not sure I agree with this(for obvious reasons :) ). DI or no DI doesn't make the design more or less coupled. In this case one of those classes needs to instantiate payment on the fly. Even if you use DI it would be lower coupling to encapsulate fully payment within Sale. It seems like a more sensible design would be to have Register acceptPayment(p) and create a sale, but its not my register – nsfyn55 Apr 20 '11 at 18:32
  • Register Should be the one delegating this task to Sale, otherwise register will become incohesive – user478636 Apr 20 '11 at 18:39
  • @nsfyn55 you say DI doesn't (make the design more or less coupled) :) I say it does - with DI Paymant can be reused... it can even have one instance ;) – dantuch Apr 20 '11 at 18:41
  • 1
    thats not coupling though. The form of coupling espoused by number two is called Content Coupling. "Content coupling infers that changing the way the second module produces data (location, type, timing) will lead to changing the dependent module.". In two both Sale and Register are content coupled to Payment's API. In one only sale is. How many instances you have floating around is irrelevant. DI in conjunction with interfaces can be used to decouple client classes from implementations, but in this case there are no interfaces. – nsfyn55 Apr 20 '11 at 18:53
  • 1
    The simple answer is which one would require more code changes if you got rid of Payment. Any way you cut it the answer will be number 2 because in number 2 there are two touch points with payment. – nsfyn55 Apr 20 '11 at 18:57
1

In the first one payment is coupled to Sale. In the second one its coupled to Register and Sale. I would say the first has lower coupling because Register has no concept of payment. Payment could completely eliminated completely and would require no changes to Register. In the second if you eliminated Payment both Register and Sale would need to change.

nsfyn55
  • 14,875
  • 8
  • 50
  • 77
  • From a creator point of view, A register records payment. So it contaisn information about payment. So by definition, it should create payment no? – user478636 Apr 20 '11 at 18:38
  • 1
    Thats not relevant. if you got rid of all the Registers, Payments, and Sales, replace them with Object1, Object2, and Object3. I would say that one is the most decoupled. Draw a simple dependency chart and count the lines. Way 2 - Register depends on Sale and Payment. Sale depends on Payment --> thats 3 lines. Way 1 - Register Depends on Sale, Sale depends on payment --> thats 2. 2 is less than 3 so there is less coupling – nsfyn55 Apr 20 '11 at 19:04
  • 1
    "In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules." – nsfyn55 Apr 20 '11 at 19:07
1

I don't see the point in the first example. Register is not needed?

In the second example any kind of payment can be used. (Visa, cash etc). Hence it's more loosely coupled.

jgauffin
  • 99,844
  • 45
  • 235
  • 372