« REST WARS | Main | Objects v Services: move along, nothing to see here »

The best ways I've found for implementing constructors...

...with lots of Strings in them is to normalize stuff like this:
public class CreateUserUseCase {
    public void createUser(String username, String firstName, String lastName,
boolean canCallerEditEmailAddress, String emailAddress,
String addressLine1,String addressLine2,String addressLine3, 
String addressLine4, String addressLine5, String phoneNumber,
String mobileNumber, ...
public class CreateUserUseCase {
    public void createUser(Name name, List EmailAddresses, Address address, List phoneNumbers,...

The problem with these String driven constructors or create calls is that they grow and grow and grow. They're never done; each addition requires a change to the published interface. You wind up with half a dozen of them and ultimately the interface becomes a mess (it's less common in Java, but for some reason a lot of production VB code I've come across looks this way). Methods like this are often a sign you're moving from the world of transaction scripts to a domain model. Less often, it's a sign that the relational data model you were provided with contained assumptions (and especially one to one relationships) that no longer hold.

If for some reason creating domain objects/beans isn't an option, consider using a Map and keying each String value to a constant (or better, a URI). Although you'll be circumventing the inbuilt type checking of a language like Java, Maps offer better decoupling while scaling and evolving far better at the API level than parametric polymorphism.

January 31, 2004 06:59 PM


(January 31, 2004 11:22 PM #)

In the first example, it seems you'd be better off using arrays rather than Lists, so you can still call the method without too much verbosity:

createUser(new Name(formName), new String[] { formEmail1, formEmail2 }, ...);

Mike Hogan
(February 1, 2004 12:22 PM #)

Bill, this software craftsmen post is about adapting "bags of strings", things like HttpServletRequest and Excel rows into something usable by a use case impl, which will create Names and Address objects.

Its simpler that way. Otherwise your Struts action has to construct Name and Address objects by getting strings from HttpServletRequest and putting them into name - get/set, get/set - makes me sick. And your Excel data loader has to do the same. Its cleaner if the use case impl does the domain object construction, and just says to the struts action and the excel loader (and others) "if you adapt your bag of strings to look like this, I'll do the rest".

Trackback Pings

TrackBack URL for this entry: