Posts Tagged ‘Pragmatic’

Demeter’s Law

Friday, January 18th, 2008

So, I’m still working my way through The Pragmatic Programmer (yeah, I’ve been busy) and just went through the chapter on Demeter’s Law. I have to say, I’m a little skeptical. The general idea is that you only use objects and methods of objects that your current method(or class) “owns” directly, not things that other objects own. So for example, if your object takes a “Customer” object containing a “Person” object, you should not call Customer.Person.FirstName, because you don’t own the “Person” object. Instead, you should use a wrapper getter in Customer that gets FirstName from Person (CustomerFirstName, say). And if Customer was inside of Order, and you wanted the Customer’s first name from Order, the proper thing to do would be to wrapper the CutomerFirstName up, maybe with BuyerFirstName.

SO, instead of Order.Customer.FirstName

you’d have Order.CustomerFirstName

And THAT you can safely call. What’s the reasoning for this? well, this allows all kinds of changes to Person and FirstName, and once the class is changed in Customer, nobody else needs to know anything happened. since everything else is a wrapper, everything else will just work. Problem? well, Order, instead of being a stripped-down class just dealing with order-related stuff ends up possibly being an enormous class full of Customer and Person wrapper stuff, and depending on what other objects Order has, it could be even worse. Pragmatic suggests dealing with this by using a code generator… Frankly, though I see how coding this way would be safer, the idea of having huge amounts of wrapper crap kinda feels like a smell. Maybe this is worth it, but I’m not quite sold yet on it being worth the clutter. I’m going to have to think about this one a bit more.

The Pragmatic Programmer

Sunday, December 16th, 2007

I’m about 3/4 of the way through this. I’d heard a lot of it from other people so there’s not a lot that’s stunningly new, but it’s a good introduction to a lot of better principles. In particular, I’d heard about the DRY principle, but it was good to actually read about it. Some of the stuff about coding defensively seems good, but I feel like it could be going a bit overboard. The discussion of the constraints in Eiffel sounded interesting, and I hear RSpec has something interesting. Something to look into…