aspose file tools*
The moose likes Java in General and the fly likes Which implementation is better: Calling methods by several arguments or encapsulating in an object? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Which implementation is better: Calling methods by several arguments or encapsulating in an object?" Watch "Which implementation is better: Calling methods by several arguments or encapsulating in an object?" New topic
Author

Which implementation is better: Calling methods by several arguments or encapsulating in an object?

Ravindranath Akila
Greenhorn

Joined: Jun 27, 2009
Posts: 4
(sorry fellas I wrote a huge post on this but a bug in the site ignore my post so now I am posting only my results below. Please provide feedback)





[MethodParameterCheckZip.jpeg]


Sincerely,
Ravindranath Akila...
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

"Better"? Depends on the situation. For three arguments I personally probably wouldn't bother--but it depends on what the three arguments are, how they're related, are they used across an entire application, etc.
Ravindranath Akila
Greenhorn

Joined: Jun 27, 2009
Posts: 4
"Better"? Depends on the situation


Exactly.

If we need to "log" the arguments or "validate" them, this approach is good.

If we need to overload the method extensively, this approach is much better.

If we need to impose constraints on the arguments, this approach is much better.(Use of constructors or custom methods to set values for private variables)

If we need to change the internals of the receptor method and accept additional parameters for a new implementation, WHILE maintaining code for the old implementation, this approach is better.

but it depends on what the three arguments are


Yes.

Some time back, I was developing an interface which accepted search criteria. This very functionality was used in several places of the project, with minute customizations. What happened was, I ended up using optional arguments to methods and had to handle multiple return values. This was due to the fact that, some interfaces had pagination for the results, and some interfaces had to store a cursor value which was also required for pagination. The code finally was perfect, but not "humanly readable".


If I may post my opinion, I feel when ever user inputs are taken(i.e. when validation, logging etc. is required), this "Bean As An Parameter" works perfect. In the event of implementing complex stuff as mathematical algorithms, it simply becomes a design and readability requirement.

My keen interest on this is, why haven't I read about any posts, articles or books on this approach so far. Is it because there is a severe best practice violation made here that talking about it is absurd? or is it that nobody really bothered to use it? It doesn't seem to be slow.

I feel this approach would bind perfectly with JSR 303.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

People use this approach all the time; it's even available as a refactoring in some IDEs and is one of Fowler's refactoring patterns (IntroduceParameterObject).
Ravindranath Akila
Greenhorn

Joined: Jun 27, 2009
Posts: 4


That was quite an unsupported statement by me. Let me elaborate.

If we do have domain/value objects, then definitely we'll be passing them as arguments. But do we all the time encapsulate arguments, which infact are not domain objects, as an argument for a method? I am confused, because,

I have never read anywhere saying "Encapsulate your method arguments in a bean so that you can log, validate, and impose constraints on them". Maybe I am illiterate on this matter.


Since I started programming, Classes were for me a set of closely related tasks in relation to an entity, and Methods were granular tasks. Parameters passed to them were always "go together". But I never used something like




which I could change seamlessly into





and modify my swap method to use say "instanceof" without affecting the callers of swap. Use of generics here would be even better.

On the other hand, multiple return values can also be easily encapsulated into a Bean instead of using object arrays which I see so often, as a solution.

My point is, I have never seen anybody point out this type of implementation anywhere. We DO always use this format by passing domain objects, beans to and fro. I never took this point of view. It always *happened to be a bean. Not that a bean as a parameter approach was a "consideration" during design.


Does this mean I've been in the dark so far? I haven't seen this in even in Thinking in Java(Bruce Eckel) or any other places though.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Well, Fowler's Refactoring book was out circa 2000, so it's been an "official" pattern since at least then.
Ravindranath Akila
Greenhorn

Joined: Jun 27, 2009
Posts: 4
Will get back to this with a more vivid example. Thanks
Mathieu Poitras
Greenhorn

Joined: Aug 22, 2008
Posts: 3
There is some cases where you have to pass many arguments, and in these cases I would advocate that an encapsulating bean is better. However, my first reflex when encountering a method that takes many many arguments is: "Does the method tries to do too much? More than one thing?". Very often, this is the issue, not the way the arguments are passed.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Which implementation is better: Calling methods by several arguments or encapsulating in an object?