Using builder pattern

[errael]

(This discussion started in an email thread, I'll adapt them and post after this intro.)

I'm not that familiar with the builder pattern. But after some exposure, and then considering some problems I've recently run into, it occured to me that using a builder can affect

• simplify - there's one way to set it up
• document - the builder doc shows the knobs
• reliable - avoid problems if things are done or used out of order
• maintain - and enhance simpler with setup/operate clearly partitioned

Perhaps I'm being optimistic. (I've discovered that there isn't anything I can't screw up)

[errael]

A common pattern is to have methods to set up various things, for example with SSDBComboBox there's

setQuery()
setPrimaryKeyColumnName()
setDisplayColumnName()
setSecondDisplayColumnName() // optional

in addition there's an execute method that uses the above information.

I haven't tried, but I'm guessing that if execute before everything is setup then that's a problem. Or if things are set up, then exectue, then do the optional setSecondDisplayColumnName() havoc would ensue. Making the setup atomic avoids problems, you've got one of

• needing a lot of code to make sure things are done in the right order
• let things go haywire if not used correctly

Something like

   ssDBCombBox.changeQuery()
        .sql("select ....")
        .mappingColumnName("foo")
        .optionColumnName("bar")
        .option2ColumnName("baz"); // is optional
        .build();
        // .async(threading_info) blue sky

With it all specified at once, the build() checks consistency and that all the info has been supplied, and if all looks good then this becomes the current info "atomically", all ready for an execute.

I'm not sure this is as useful in ssComboBox (but for consistency?), if it is then the .mappingColumnName() equivelent is optional as well, if it is not specified, then you get a [0-N) mapping. Or you could require .zeroToN() and if both or neither is specified it's an error.

One issue is what to do if there's an error during build(). My inclination is to throw an exception and make the combo box blank. It feels wrong to leave the previous setup in place and return false.

Then all those setters: setPrimaryKeyColumnName, setQuery, ... go away along with all those firePropertyChange.

I need to read about the builder pattern in java, maybe now I'm primed to get it.

[errael]

An option is to keep the individual calls but add some consolidation methods such as the builder pattern under discussion

Keeping the old setXxx() methods defeats some of the main benefits. You'd still need a bunch of code to make sure things are done in proper order (or it's the wild west), reliability and maintenance are more difficult.