Andrew Bennetts wrote:
Jamie Wilkinson wrote:
2008/7/25 Ben Leslie <[EMAIL PROTECTED]>:
On Thu, Jul 24, 2008 at 6:37 AM, Adelle Hartley <[EMAIL PROTECTED]> wrote:
When I'm coding in C++, I tend to spell things out more, but I put that down
to my lack of knowledge & experience.
Unless there was a reason to use the intermediate variable I would always
use 'run-on dereferencing'. And would probably get people to change to
run-on dereferencing in a code review if I saw it in other people's code.
+1 with 3 exceptions:
[...]
I'd also add that *sometimes* http://en.wikipedia.org/wiki/Law_of_Demeter is
worth heeding. That is, if you're doing “a.b.c.d.e” (with or without temporary
variables) then maybe your abstractions aren't quite right. If nothing else, it
can be a pain in the neck to write unit tests for a method that dereferences
through multiple levels, because of all the test doubles you need to provide.
Good point.
I do sometimes wrap the ".b.c.d" in a method in a.
eg.
public class Customers
{
public IEnumerable<float> ExchangeRates
{
get
{
return Countries.Currencies.ExchangeRates;
}
}
}
or even just
public class Customers
{
public Currencies Currencies
{
get
{
return Countries.Currencies;
}
}
}
So I can replace Customers.Countries.Currencies.ExchangeRates with
either Customers.ExchangeRates or Customers.Currencies.ExchangeRates, in
either case reducing the amount of knowledge I rely on regarding the
Customers class - which I think was your point, although I never thought
about it that way before. I was just trying to save some typing in the
caller.
I've usually typed a.b.c.d a few times before I do that.
For code that's been generated from an E/R model, I wonder if methods
for a.d, a.c, and a.d can also be generated in the cases where their
meaning would be unambiguous. Would that even be a good idea?
Adelle.
_______________________________________________
coders mailing list
coders@slug.org.au
http://lists.slug.org.au/listinfo/coders
