3 ms·
Where's the added coupling? Before you'd have two accessors returning their own type, one of them nullable. Now you have one method that doesn't return. That in
by lolc 8y ago
Where's the added coupling? Before you'd have two accessors returning their own type, one of them nullable. Now you have one method that doesn't return. That interface is also agnostic of how customers can be reached: If we add sendByPigeon() the Customer interface won't see change.
The customer object is in a good position to decide how the customer should be reached.
- lucozade 8y agoIt's coupled the Customer to the service announcements without there being any need to. At least in the first refactoring. The second refactoring is somewhat different. That would make more sense if the communication decision wasn't based solely on the existence of an email address. But all he's really done now is add a kind of bespoke Visitor pattern to work around a lack of double dispatch. Personally, I'd be inclined to keep the naive version unless there were clear requirements for double dispatch (and probably more than one example). If there were multiple requirements, I'd build in an abstract Visitor framework so you're back to limited coupling at the expense of some complexity. TBH I'd probably be using a language that had multiple dispatch but that's not always an option.
- lolc 8y agoYou're forgetting the calling code in your accounting: While the Customer objects learns about Announcements, the calling code (we don't see) forgets about EmailAddress and PostalAddress. That means less coupling overall.