Comments on: Coding: Coupling and Expressiveness

By: Coding: Connascence – Some examples at Mark Needham

Coding: Connascence – Some examples at Mark Needham — Wed, 28 Oct 2009 12:44:24 +0000

[...] think this principal is quite similar to the idea of coupling which we seem to use more frequently these days but I found it quite compelling that as I was [...]

By: Coding: Reduce fields, delay calculations at Mark Needham

Coding: Reduce fields, delay calculations at Mark Needham — Wed, 02 Sep 2009 13:54:00 +0000

[...] 'SomeObject' and 'Dependency1′ and 'Dependency2′ by storing those in fields and I was pondering the wisdom of doing this sort of thing in a previous post but I think I prefer to take this coupling over the alternative [...]

By: Andy Palmer

Andy Palmer — Tue, 01 Sep 2009 10:09:04 +0000

I was definitely thinking TinyType too.

I wouldn't worry about LoggedInUser being created elsewhere. The best kind of system is the one that is simple enough to be used in previously unthought ways

By: Coding: Coupling and Expressiveness at Mark Needham | Coupling live today

Coding: Coupling and Expressiveness at Mark Needham | Coupling live today — Fri, 28 Aug 2009 05:54:53 +0000

[...] connector which is the loosest identify of connector that we crapper … Excerpt from: Coding: Coupling and Expressiveness at Mark Needham Posted in Uncategorized | Tags: a-nice-post, and-from, cohesion-and, different-types, [...]

By: DotNetShoutout

DotNetShoutout — Thu, 27 Aug 2009 13:49:29 +0000

Coding: Coupling and Expressiveness – Mark Needham…

Thank you for submitting this cool story – Trackback from DotNetShoutout…

By: Twitter Trackbacks for Coding: Coupling and Expressiveness at Mark Needham [markhneedham.com] on Topsy.com

Wed, 26 Aug 2009 00:39:24 +0000

[...] Coding: Coupling and Expressiveness at Mark Needham http://www.markhneedham.com/blog/2009/08/25/coding-coupling-and-expressiveness – view page – cached Thoughts on Software Development — From the page [...]

By: Zach Shaw

Zach Shaw — Tue, 25 Aug 2009 22:24:15 +0000

You know, another way to cut down on people abusing this method, keeping down the coupling, and revealing the intent (maybe ) could also be to invert the control of the Retrieve method, it might be a little ugly, but you could do something like:

void Retrieve(CustomerReader customerReader) {
id = customerReader.getCustomerId();
//look stuff up
customerReader.setCustomer(theCustomerWeFound);
}

Where LoggedInUser implemented CustomerReader.

If I was presented with this method I would look for types that implemented CustomerReader to see who I should be passing into the method, and probably not implementing my own type to pass in.

By: Dave Cameron

Dave Cameron — Tue, 25 Aug 2009 21:22:33 +0000

I was thinking "TinyType!" while reading this. I think CM and Zach have already suggested essentially a TinyType. Or is TinyType significantly different from a class with one field?

By: Zach Shaw

Zach Shaw — Tue, 25 Aug 2009 18:37:23 +0000

What jumped out at me when I first looked at the code was that I've gotten yelled at plenty for passing around primitives. So I can't help but ask, why not pass a CustomerId object instead of a String? The CustomerId could simply hold the string, but it would be clearer from the API perspective what the method wants, and you'd cut down on the coupling.

By: Chris Ammerman

Chris Ammerman — Tue, 25 Aug 2009 15:28:30 +0000

Cross-layer coupling is bad, but a certain amount of coupling among classes and interfaces *within* the domain layer is expected. And since the interface of a repository is generally considered to be part of the domain, I tend to think that coupling the repository interface to a domain object such as a LoggedInUser is perfectly natural.