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 -~----------~----~----~----~------~----~------~--~---
