It's called varargs; http://docs.oracle.com/javase/6/docs/technotes/guides/language/varargs.html

It means you can pass an arbitrary number of arguments to the method (even zero).

In the method, the arguments will automatically be put in an array of the specified type, that you use to access the individual arguments.

(String ...) is an array of parameters of type String, where as String[] is a single parameter.

Now here String[] can full fill the same purpose here but (String ...) provides more readability and easiness to use.

It also provides an option that we can pass multiple array of String rather than a single one using String[].

It is an array of String arguments that are passed into the main method from the input of the application, so for example you can run a program using: java helloWorld.java And you can also input arguments to be used by the main method using: java helloWorld.java {string1} {string2} and then in the main method you can access these values using args[0], args[1]

String.format()

Since Java 5, you can use String.format to parametrize Strings. Example:

String fs;
fs = String.format("The value of the float " +
                   "variable is %f, while " +
                   "the value of the " + 
                   "integer variable is %d, " +
                   " and the string is %s",
                   floatVar, intVar, stringVar);

See http://docs.oracle.com/javase/tutorial/java/data/strings.html

Alternatively, you could just create a wrapper for the String to do something more fancy.

MessageFormat

Per the comment by Max and answer by Affe, you can localize your parameterized String with the MessageFormat class.

Hi there, In short, I think it is just a convention that works across multiple languages. It makes for clearer code and demands consistency in the creation of objects. It would help in examples of inheritance also making the code clear. Java will create a default constructor for a class if you don't declare one explicitly. Java won't know you've done that unless you adhere to the convention. So, if you don't then the constructor won't get called at the point of instantiating an instance of the classas Java will use its own default constructor. Without this convention, the compiler won't know which method is a constructor and which are just instance methods so there needs to be a way of clearly defining that. Make sense? Steve.

I would discourage you to ever use null since it can lead to a further NPE, which are hard to debug (and cost a lot if they occur in production code).

Solution 1 (overload method)

If no deviceName is provided, you can provide a default one instead. The biggest disadvantage from this approach is the danger in genericDeviceMap.put(deviceName, device) because it can silently override the entry whose key is the default name (therefore, losing track of the previous Device).

public void attachDevice(Device device)
{
    attachDevice(device, "DefaultName");       
}

public void attachDevice(Device device, String deviceName)
{
    ..
    device.setName(deviceName);
    genericDeviceMap.put(deviceName, device);
    ..
}

Solution 2 (extract method)

Maybe that with your current architecture it doesn't make sense to add an entry to genericDeviceMap when attachDevice is called without a name. If so, a good approach is to only extract the common behaviour between the two attachDevice into private methods. I personnally don't like this approach for 2 reasons:

• The behaviour between the two attachDevice is not the same, one has a side-effect (device.setName(deviceName)) and the other not
• The side-effect in itself who often lead to subtle bugs because you alter an object who's coming from an outside scope

Code:

public void attachDevice(Device device)
{
    preAttachDevice();
    postAttachDevice();      
}

public void attachDevice(Device device, String deviceName)
{
    preAttachDevice();
    device.setName(deviceName);
    genericDeviceMap.put(deviceName, device);
    postAttachDevice();
}

private void preAttachDevice()
{
    ...
}

private void postAttachDevice()
{
    ...
}

Solution 3 (remove method)

My favorite, but the hardest. Ask yourself if you really need these two methods ? Does it make really sense to be able to call attachDevice either with a name or not ? Shouldn't you be able to say that attachDevice must be called with a name ?

In this case the code is simplified to only one method

public void attachDevice(Device device, String deviceName)
{
    ..
    device.setName(deviceName);
    genericDeviceMap.put(deviceName, device);
    ..
}

Or on the other hand, do you really need to maintain a Map of devices and devices names and set the device's name ? If not, you can get rid of the second method and only keep the first one.

public void attachDevice(Device device)
{
    ...
    ...     
}