Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe01.iad.POSTED!not-for-mail From: Daniel Pitts User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Wormholes References: <0ska4895k2mp2j5fb5p4qnue7lsbdpoeoo@4ax.com> In-Reply-To: <0ska4895k2mp2j5fb5p4qnue7lsbdpoeoo@4ax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 43 Message-ID: X-Complaints-To: abuse@newsrazor.net NNTP-Posting-Date: Tue, 04 Sep 2012 16:28:18 UTC Date: Tue, 04 Sep 2012 09:28:14 -0700 X-Received-Bytes: 2755 Xref: csiph.com comp.lang.java.programmer:18540 On 9/3/12 6:12 PM, Roedy Green wrote: > I run into this sort of problem fairly often. > > I have a method x that calls method y through a long chain of > intermediate calls. > > I decide to add a feature. Method x has access to information to > decide if the feature should be implemented. Method y is where the > implementation is. > > Somehow I must pass information down the long chain from x to y. This > means changing the signatures of all the intermediate methods, and > adjusting code to the new way. This can cause ripples incommensurate > with the triviality of the change. > > I imagined some sort of wormhole to allow information in one place to > simply be known somewhere else without the excess exposure of public > variables or tediously arranging transport. I read about Eiffel a > long time ago. IIRC you could provide a list of precisely who could > see any given information. > > I wondered if anyone had thoughts on ways of tackling such a problem. > If you arrange to pass-through a Parameter Object instead of a bunch of related parameters, this could solve your problem in many (not all) cases. The primary benefit of a Parameter Object is that you can add new fields (if they have sensible defaults) without a rippling change to all existing users of the method which takes the Parameter Object. There are other potential benefits as well. Your Parameter Object might have a nice "Builder" counterpart which makes it easier to specify optional parameters (using call-chaining for example). A special case of the Parameter Object is often called the Context. Many types of frameworks pass around a Context object to all methods. The HttpServletRequest object is such an example (a.k.a The Request Context). This is a more generic form than Parameter Object, and I don't suggest it for most usages, as you can end up with name-collisions, type problems, and other problems that can't be diagnosed at compile time.