Reference a method's parameters in one variable

Question

I have a method

public void create(String x, String y, String z, Calendar a, Calendar b, Calendar c, List<String> d){
    object.create(x, y, z, a, b, c, d);
}

which gets passed around trough a few managing classes. Is there a way that avoids me having to explicitly type the parameters in the object.create call but instead allows me to simply reference the method's own parameters?

The reason I'm asking this is because I have several of these methods and it would look pretty messy.

Do note that the parameters are of different types and they should still be defined as such and not as Object... args.

T.J. Crowder · Accepted Answer · 2013-03-11T18:47:57.810

5

The usual answer here is to create a new class which has properties for these things, and pass around an instance of that class (sort of as a message envelope) rather than a bunch of discrete arguments.

For example:

public void create(MyNiftyThing thing){
    object.create(thing);
}

...where the MyNiftyThing class is:

class MyNiftyThing {

    private String x;
    private String y;
    private String z;
    private Calendar a;
    private Calendar b;
    private Calendar c;
    private List<String> d;

    public MyNiftyThing(String x, String y, String z, Calendar a, Calendar b, Calendar c, List<String> d) {
        // ...init data members here...
    }

    // ...accessors for the data members here...
}

You can keep it immutable by only having getters and not setters. Sometimes, if it's purely a convenience data structure, you might use publics for the instance members, but any decent IDE can auto-generate the accessors for you (and if you used publics, you'd be stuck with final for immutability).

Of course, you don't have to accept all of those in the constructor (or you can have multiple constructors), if there are reasonable defaults you can supply.

It probably doesn't apply to this specific case, but for instance MyNiftyThing can be its own builder by having a constructor accepting minimal args (possibly none) and then a series of buildNNN methods that set their relevant data member and return this for chaining. That can help avoid getting lost in the constructor signature ("Was it x, y, z or x, z, y...?"). :-) The downside to that is that you essentially lose immutability.

edited Mar 11 '13 at 18:47

answered Mar 11 '13 at 18:22

T.J. Crowder

1,031,962
187
1,923
1,875

All of these variables will eventually result in the creation of an object. However, validation of the input parameters will only be done in the last managing class in line in order to maintain its specific task. Creating an object with these variables would bypass this, which is unwanted behaviour. – Jeroen Vannevel Mar 11 '13 at 18:25
@JeroenVannevel: It doesn't have to. You can validate them at the end if you like, basically treating the class a message envelope. – T.J. Crowder Mar 11 '13 at 18:25
In this specific case an object will be created and added to the database. Are you suggesting I add it to the database, validate it and remove if necessary? – Jeroen Vannevel Mar 11 '13 at 18:26
@JeroenVannevel: No, not at all. You've said you're passing these things around a lot and that it's messy. I'm saying you can do that somewhat more cleanly (and certainly more concisely) by putting them in an envelope. At **exactly** the same place you would have validated `x`, `y`, etc., as discrete arguments, you can validate `nifty.x`, `nifty.y`, etc. There's no difference except how you move that data around your code. (That is, there doesn't *have* to be a difference; there's certainly the opportunity for going further if you want.) – T.J. Crowder Mar 11 '13 at 18:29
I see, you're suggesting I create a new class which holds these fields but different from the one that will eventually be created with these variables, is that correct? – Jeroen Vannevel Mar 11 '13 at 18:30
@JeroenVannevel: Right, just a message envelope, effectively. – T.J. Crowder Mar 11 '13 at 18:31
@JeroenVannevel: No worries! :-) – T.J. Crowder Mar 11 '13 at 18:32
1

I'd make that immutable, for the usual reasons. – Tom Hawtin - tackline Mar 11 '13 at 18:45
@TomHawtin-tackline: Immutable would make good sense for the "everything in the constructor" version, no question. Harder for the "builder" version (probably added that as you were commenting). – T.J. Crowder Mar 11 '13 at 18:48

score 1 · Answer 2 · edited May 23 '17 at 10:25

1

It is possible using reflection, and if your code is compiled with debug enabled; see the following answer: Can I obtain method parameter name using Java reflection?

edited May 23 '17 at 10:25

Community

1
1

answered Mar 11 '13 at 18:24

Dexygen

12,287
13
80
147

Reference a method's parameters in one variable

2 Answers2