To highlight the 'it depends' when deciding on delegate methods using associated objects ( ie User.getDepartmentName() ) or simply chaining ( ie User.getDepartment().getName() ) its no accident Fowler has 2 refactorings, Hide Delegate and Remove Middle Man that do opposite things with no clear rules determining which way you should go.
As you know my question was specifically on chaining methods on the same object which you answered in your post too. Alan ________________________________ From: Brian Kotek <[email protected]> To: [email protected] Sent: Sunday, January 4, 2009 4:29:15 PM Subject: [CFCDEV] Re: Method chaining It depends on the situation and what you're actually chaining. There's a well-known rule about this called the Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter), part of which states, in essence, "use only one dot". In other words, this: user.getRole() would be preferable to this: user.permissions.role It probably goes without saying that there is debate on this subject. The main idea is to try and limit how much one class knows about other classes (low coupling). Clearly, this user.getRole() I know only about the User object, but with user.permission.role, I now depend on User having a permissions property, and then on permission having a role property. I've essentially doubled the coupling with the second version. I'd say that in general, limiting chaining of this type would be a good decision, but as always, reality wins. I don't think it's feasible to write "wrapper" methods for every conceivable call an external object might make to a composed object. If you have to do it, do it, but it might be wise to at least stop and ask yourself "is this really necessary" before you do it. On the other hand, several of the examples people have posted in this thread seemed to actually be chaining off a single object multiple times, such as: result = session.createCriteria(My.class) .add(....) .add(....) .add(....) .list(); which to me is totally fine since it doesn't actually violate the Law of Demeter. It's just a convenience to avoid typing the same thing on multiple lines since each of the methods is actually returning "this". You're still working with the same object, not nested properties or associations. So I suppose that after all that, my answer is probably the not-extremely-helpful "limit its use if you can, and try to use it appropriately"? ;-) regards, Brian On Sun, Jan 4, 2009 at 4:50 AM, Alan Livie <[email protected]> wrote: I have just read some code in a Hibernate book that uses a lot of method chaining ie setFoo(1).setBar('myvar').setThis(x).setThat(y) etc I remember some old Open University days doing Smalltalk when method chaining was common as there was no VOID return type on methods so setter methods tended to return THIS.I have also seen this a lot recently doing jQuery work ie $("a").addClass("test").show().html ("foo"); The methods return the jQuery object so chaining is possible. In CF (at least the code I've read and written) we don't tend to do this. Is this for readability reasons or something else I'm not aware of? I think setter methods (and maybe other methods that return VOID) returning THIS is a sensible idea so we can chain or not chain as we see fit. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
