I agree with Kirk, one should always aim at having as few arguments as possible for a variety of reasons and if you think in abstractions/ contexts it should be possible. It's fine to make up and pass DTO's (synthetic objects), even if Java makes this a very ceremonial thing to do. It also seems to fits the bill "a method should do only one thing" quite nicely.
Notice I say DTO because I actually think there's a subtle but not insignificant difference between an object exposing behavior and a data structure encapsulating state - again even if Java puts both into the same camp. On the one hand, you can easily add new methods all over without every touching the DTO itself. On the other hand, through polymorphism you can easily introduce new objects without ever changing existing methods. Double dispatch is handy but it requires the gift of foresight (back to design again) and effectively breaks encapsulation, and that's not really a desirable option across API boundaries. There's no one size fits all solution to this problem I think. /Casper On Dec 19, 9:34 am, kirk <[email protected]> wrote: > etzel wrote: > > Meanwhile I've read a little bit further in the book. In chapter 7 > > this topic comes up again and Steve McConell says that there are > > really two camps. > > > The one say that you should pass just the parameters needed for the > > calculation because it's more loosely coupled, easier to read and that > > passing an object is violating encapsulation (of this parameter > > object). The others say that it makes the interface more stable when > > the method takes the object as a parameter, because the method could > > take into account any other attribute of that object for its > > calculation without changing the interface. > > > Steve McConnel then says that both are two simple: It's more about the > > abstraction the method provides. > > > Further, if you pass an object you can recognize that you should have > > passed the parameters instead if you create the object just for the > > method call, setting the parameters needed for the calculation, pass > > it to the method which just unwrapps the parameters from the object. > > If you chose to pass the parameters to the method you can recognize > > that you should have passed an object instead if you frequently change > > the signature of the method, always adding/removing a parameter that > > always belongs to the same type of object. > > Long parameters lists are a code smell, missing design element. Maybe > that synthetic object is really more important and what is really > missing (after a refactoring) is an opportunity to exploit double > dispatching. In that case you'd maintain information hiding by having > the caller and the callee both participate in the calculation by adding > what they know to the result and not by interrogating each other. > > Serialization is a good example. You write.. > > out.print(myObject); > > is implemented by serialization as an immediate call back to your > read/write methods. > > object.write( out); > > and that is implemented but the object writing each of it's individual > parts onto the stream. This ping-ponging of the calls (double > dispatching) eliminates the need to inappropriately interrogate an > object for it's internal state thus allowing you to maintain > encapsulation. That said, it does nothing to eliminate the coupling as > both parts are coupled to each other. And that is the case with Steve's > suggestion, it's still a coupled implementation. What is being aimed for > is a more appropriate coupling. > > I should add I have a strict definition of coupling. If class A is > needed to compile class B, then class B is couple to class A. Breaking A > into constituent parts only hides the coupling, it doesn't elminate it. > You still need those bits and now they are no longer bound into a useful > gestalt. > > Regards, > Kirk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
