（Java）重载：多少是太多？

Question

I'm using Java to generate JCL. I have four methods for adding a data definition statement. One accepts a char, one a string, one an array (of Strings), and the other has nothing for the second parameter.

public void addDD (String label, char classChar) //Generates: SYSIN DD SYSOUT=[classChar]
public void addDD (String label, String dataset) //Generates: SYSIN DD DSN=[dataset]
public void addDD (String label) //Generates: SYSIN DD DUMMY
public void addDD (String label, String datasets[]) //Generates: SYSIN DD *
                                                    // DSN=[datasets[0]],
                                                    // DSN=[datasets[1]]

The concern I have is that these methods don't just accept different parameter types; the entire method changes based upon the type. If it's a string, you need "DSN=". If it's a char, you need "SYSOUT=". At the same time, I don't want the client to worry about using a different method name for each of these scenarios.

Is my current design considered bad practice or good?

Answer 1

These decisions are always partly a matter of taste.

In this particular case, I would rather change the method names as they really do something different. Most of the time overloading methods like this is just convenience: having a char or String variant mostly means that the char will be converted to a string and the effect will be the same, which isn't the case in your example.

There might be other reasons for doing this like you did (using reflection to find the correct method), but in that case I would recommended writing clear Javadoc describing that the methods actually do to avoid confusion.

Answer 2

What you're doing is quite dangerous - you counting on the caller of addDD(String, char) to read the javadocs and figure out he shouldn't be using addDD(String, String) instead.

Option 1 : rename the methods: addDDSysout() , addDDDsn() etc.

Option2 : implement all these with just a single method:

addDD(String label, String... args)

and make very sure you can handle anything thrown at it - no strings in args, a single string, multiple strings, a single character etc.

Answer 3

I have to agree that these things are often a matter of taste. But I'm not sure the other responders understood the significance of a JCL DD statement. Because I disagree with them based on the domain of your problem.

I like your design. I would discourage different method names. That is basically what TSO did with FILE(xxx) vs DSN(xxx) and I always hated it. While you're methods produce different "results" in the input reader stream, these differences are forced by the syntax of JCL. To be more specific they don't do different things . Fundamentally you are declaring a data source/sink to a batch job. Don't make your user learn 4 different methods to do that.

Answer 4

The number of method signatures needed to cover all DD statement constructs could become quite messy.

For example, I'm not too sure that method:

public void addDD (String label, String datasets[]) 

which generates:

//SYSIN DD *
// DSN=[datasets[0]],
// DSN=[datasets[1]]...

is going to work very well, the DD * indicates inline data to follow, and that needs to be terminated with a /* before concatenating additional datasets (if any). The above method should probably generate a simple series of DD statements as follows:

//SYSIN DD
// DSN=[datasets[0]],
// DSN=[datasets[1]]...

What sort of signature would you use to generate an inline dataset? Probably the same thing:

public void addDD (String label, String inlinedata[])

to generate:

//SYSIN DD *
inlinedata[0]
inlinedata[1]...
/*

But both methods have the same signature - that doesn't work. You might be better off using multiple methods to avoid signature collisions. Or if you continue with the overloaded single method, then be sure you have all the possible DD name constructs covered before getting too deep into the swamp.

Either way, this is going to require a significant amount of documentation for end-users to make sense of (JCL can be a real dog of a scripting language to follow).