When Do You Violate The Law of Demeter In ColdFusion OOP Development?
Posted May 22, 2007 at 8:18 AM by Ben Nadel
Kola Oyedeji just wrote a very nice article for the ColdFusion Developer's Journal on applying the Law of Demeter in ColdFusion object oriented programming (OOP). In his article, Kola summarizes that according to the Law of Demeter, an object should only call methods that:
- Belong to itself (i.e., its own methods)
- Are on objects passed in as a parameter
- Are on objects created by the object
As I learn more about object oriented programming (OOP), this makes a lot of sense to me. But, as Kola mentions, all laws/rules/best practices have a trade off. Strictly following this law might bloat your ColdFusion components with numerous methods that do little more than delegate calls to composed components. So the question I have is, where do you find that you most often break this law for the trade off of programming convenience?
The one example that he covers, a person's address, seems like a likely place to break this rule. I feel that people would rather do something like:
- objPerson.GetBillingAddress().GetStreet()
... rather than:
- objPerson.GetBillingAddressStreet()
And imagine if we were dealing with two composed address objects: one for billing and one for shipping. The number of delegating methods could get out of hand. My gut feeling tells me that address is a solid enough component that it can have its methods called via dependency chains. But then again, I am not an object oriented ColdFusion programmer just yet.
So, where do you choose to violate this law?
Reader Comments
For something like that, I'd probably do something like
objPerson.getFormattedAddress()
The objPerson object has a handle to the address object, so it would just call the variables.billingAddress.getFormattedAddress() method on it which returns a readable address (or maybe one marked up with the addr microformat?). Even for that though I might just localize the address object and use it natively, rather than through the getBillingAddress() chain. That would depend on just how often you want the users address.
objBillingAddress = objPerson.getBillingAddress() Then go from there as normal. But as for creating single delegates like that with no logic of their own, I'd try to avoid it whenever possible for objects.
@Adam,
When you say:
"But as for creating single delegates like that with no logic of their own, I'd try to avoid it whenever possible for objects."
Are you talking about the GetBillingAddressStreet() method of the person object?
Yeah, for business objects at least. For SOA though, there could be delegate calls that don't do anything other than recall other services and managers, but for the business/value objects I like to keep them as compact as possible.
@Adam,
I am not exactly sure what all of what you said meant (I am learning this slowly). Are you saying that for business objects, you might use dependency chains in order to make the objects compact?
I hope that doesn't come across as a cross-examination or anything. I quite literally don't know enough about this. I am just trying to get a sense of the blend of hypothetical and practical. Thanks.
Hey Ben, I'm mostly saying that whatever needs to use the object should have access to that object, not a reference to it through another object. For instance, lets say that you're inserting a user that's just registered on your site. You get their user info (username, pass, email), and their address (default address stuff) from a form, and in the controller you populate an address object, populate a user object, then add the address object to the user object.
For saving the user object now (assuming you're making everything from the ground up), it might go something like this, starting at the controller.
controller:
serviceManager.saveUser(user);
serviceManager.saveUser(user):
userID=userManager.save(user)
userManager.save(user):
var address = user.getAddress()
var userID = userDAO.save(user.getTO)
if(address.isDirty()) {
address.setUserID(userID)
addressManager.save(address)
}
userDAO.save(userTO):
if(userTO.ID != '') updateUserOperation.execute(userTO)
else insertUserOperation.execute(userTO)
addressManager.save(address):
addressDAO.save(address.getTO)
addressDAO.save(addressTO):
if(addressTO.ID != '') updateAddressOperation.execute(addressTO)
else insertAddressOperation.execute(addressTO)
That's what I mean mostly about delegating. The user object is asked for the address object, but only to get it and give it to something else to handle it. The added bonus of all this is that you can know exactly where things belong. The DAOs never get anything other than plain old structs to insert, the serviceManager always just gets something similar and does everything from there.
In the same way as the userManager, the controller could get the newly created ID, add it to the address object, and pass it in to be saved alone. I like the idea of having almost nothing in a controller though. This doesn't really provide feedback for when something goes wrong, or worry about validation, but that's another problem. :)
I really hate serial get methods - they're ugly and unclear.
This is how I'd write it:
Person.readAddress( type:'B' , part:'Street' )
To me that makes it perfectly clear I'm reading the street part of the billing address.
@Adam,
Thanks for the very thorough explanation. I am going to let that simmer in my brain. It looks, though, like you are basically using a chain of dependencies there (reworked):
user.getAddress().setUserID( userID )
But I see that you are basically delegating work off to the individual parts. I think I need a much strong foot hold on OOP before I can fully understand the workers here. Thanks.
@Peter,
I like your idea. It would keep the number of methods smaller. The only thing people might complain about is that the method documentation is not as clear... but frankly, that is rarely a concern of mine.
Actually, Ben, you shouldn't have objPerson.getBillingAddressStreet() and 100 other similar methods. If you end up in that situation, instead of asking whether it's okay to violate LOD, ask what else you're doing wrong.
You may have methods like objPerson.sendBill(), objPerson.createInvoice(), and objPerson.getCustomerServiceRep().
That last example needs a little explanation. My assigned customer service rep might be the person who's responsible for the sales territory into which my billing address falls. So the call may drill down through three or four objects.
If CSR assignment is changed to key off of last name (Jim gets all the A-Cs, Tina gets the D-Gs, etc.) or sales territories key off telephone area code instead, clients of objPerson are unaffected. Whereas if clients of objPerson were calling getBillingAddress.getSalesTerritory().getCustomerServiceRep(), they'd be in trouble.
BTW, the Law of Demeter is very closely related to the Tell, Don't Ask principle. Check that one out as well.
