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

[Ravindranath Akila]

(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)

 

package methodparametercheck;

import java.util.logging.*;
/**
 *
 * @author Ravindranath Akila
 */
public class Main {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        Main main = new Main();
        Long startTime = new Long(0);
        int loop = 1000000;
        Logger.getLogger(Main.class.getName()).log(Level.INFO,"Loop:"+loop);

        startTime = System.currentTimeMillis();
        main.processUsualWay(loop);
        main.printTimeTaken("USUAL WAY", startTime);

        startTime = System.currentTimeMillis();
        main.processObjectWay(loop);
        main.printTimeTaken("OBJECT WAY", startTime);
    }

    private void printTimeTaken(String msg,Long beforeTimeMillis){
        Logger.getLogger(Main.class.getName()).log(Level.INFO,msg+":"+(System.currentTimeMillis()-beforeTimeMillis));
    }

    /*The usual style of passing arguments*/
    private void processUsualWay(int loop) {
        for(int i = 0 ; i < loop; i++){
            processUsualWay(new Integer(1), new Integer(2), new Integer(3));
        }
    }

    private void processUsualWay(Integer a, Integer b, Integer c){
        int x = a;
        int y = b;
        int z = c;
    }


    /*The object style of passing arguments*/
    private void processObjectWay(int loop) {
        for(int i = 0 ; i < loop; i++){
            processObjectWay(new Tester(new Integer(1), new Integer(2), new Integer(3)));
        }
    }

    private void processObjectWay(Tester tester) {
        int x = tester.getA();
        int y = tester.getB();
        int z = tester.getC();
    }

}



package methodparametercheck;

/**
 *
 * @author Ravindranath Akila
 */
public class Tester {
    private Integer a, b, c;

    public Tester(final Integer a,final Integer b,final Integer c) {
        this.a = a;
        this.b = b;
        this.c = c;
    }

    public Integer getA() {
        return a;
    }

    public Integer getB() {
        return b;
    }

    public Integer getC() {
        return c;
    }
}


Results:


run:
Jun 28, 2009 9:12:21 AM methodparametercheck.Main main
INFO: Loop:1000000
Jun 28, 2009 9:12:21 AM methodparametercheck.Main printTimeTaken
INFO: USUAL WAY:62
Jun 28, 2009 9:12:21 AM methodparametercheck.Main printTimeTaken
INFO: OBJECT WAY:94
BUILD SUCCESSFUL (total time: 2 seconds)

   

[David Newton]

"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]

"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]

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]

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

   

package methodparametercheck;

/**
 *
 * @author Ravindranath Akila
 */
public class SwapParams {
    private int ia, ib;

    public SwapParams(final int ia,final int ib) {
        this.ia = ia;
        this.ib = ib;
    }

    public int getIa() {
        return ia;
    }

    public int getIb() {
        return ib;
    }

}


 

which I could change seamlessly into

    
package methodparametercheck;

/**
 *
 * @author Ravindranath Akila
 */
public class SwapParams {
    private int ia, ib;
    private float fa, fb;

    public SwapParams(final int ia,final int ib) {
        this.ia = ia;
        this.ib = ib;
    }

    public SwapParams(float fa, float fb) {
        this.fa = fa;
        this.fb = fb;
    }

    public int getIa() {
        return ia;
    }

    public int getIb() {
        return ib;
    }

    public float getFa() {
        return fa;
    }

    public float getFb() {
        return fb;
    }

}

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]

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

[Ravindranath Akila]

Will get back to this with a more vivid example. Thanks

[Mathieu Poitras]

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.