"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.
Joined: Jun 27, 2009
"Better"? Depends on the situation
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
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.
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).
Joined: Jun 27, 2009
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.
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.