yellowstone's Journal: A software design principle

A while ago, I saw that the local library had a copy of Core Java Volume 1: Fundamentals, 8th Edition, so I checked it out and have been reading through it (the US$55 cover price makes me hesitant to go buy a copy of my own)

On page, 461, there is (among a raft of others), this particular method documented on the javax.swing. JOptionPane class:

static int showOptionDialog(Component parent, Object message, String title, int optionType, int messageType, Icon icon, Object[] options, Object default)

There are (at least) a couple problems here:

1. 8 parameters to any function is at least 4 too many
2. The above function is one of many relatively minor variations -- there are regular and internal dialogs; message, confirm, option, and input dialogs; all with a number of different overloads.

Didn't anyone with some experience with encapsulation review this API design? Seriously, how much better would it be to have something like this:

class DialogConfig {

public boolean internal; public Component parent;
public Object message;
public String title;
public int optionType;
public int messageType;
public Icon icon;
public Object[] options;
public Object default;

}

Then, you can write code that looks like this:

DialogConfig dc = new DialogConfig();
dc.internal = false;
dc.parent = parent;
// . . . etc . . .
JOptionPane.showOptionDialog(dc);

You get the benefit of 1) documenting by name, in the code, all the configuration parameters, and 2) only one method to deal with instead of many.

From now on, this is a rule, ok?

Encapsulation is a useful tool. Never ever write a function with more than four parameters.