# How to name a method that sets some values in a javabean?

Often I find myself setting various fields in a Javabean and then passing that Javabean to some method.

customerEntity.setName("Foo");
customerEntity.setAge(45);

em.merge(customerEntity);


Or

requestPayload.setCustomerId(2343);
//lots more


Not liking so much of data-population cluttering, I'd move those to a separate method..

public void doSomeOperation(Customer customer)
{
em.merge(prepareCustomerEntity(customer));
}

private Customer prepareCustomerEntity(Customer customer)
{ customer.setName("Foo");
customer.setAge(45);
return customer;
}


What would be a good name for such a method ? Maybe something like prepareXXX() or populateXXX()? Naming it as prepareXXX() makes it sound like a void method.. populateXXX() sounds better? Or should I just name it as setCustomerValues(). But setXXX() name makes it sound like a typical Javabean setter, which this is not.

• I like 'populate' personally Sep 3 '11 at 1:08

I agree you should not use setXXX() as this sounds like a classic setter. I would say go with what you think sounds nice and conveys the meaning well. prepareXXX() sound nice to me. If it is default values you are setting, you could use something along populateWithDefaultValues().

Just make sure you use the same naming strategy throughout your application.

If you can't be more specific then I'd go with populate, prepare just doesn't convey any meaning to me. Init or initialise is a more specific, and could be used if that is what you are doing, and I would prefer it to populateWithDefaultValues, which is longer.

Additionally, I personally find it confusing if a method mutates a parameter and then returns it. I understand the convenience of being able to do something like em.merge(prepareCustomerEntity(customer)), but I think it bastardises the method design.

• What if the parametr is immutable? Sep 5 '11 at 7:40
• Then it makes more sense, and I'd go with something along the lines of Customer newCustomer = newEntityWithDefaults(customer) Sep 6 '11 at 8:16
• Yep, it sounds very confusing. Thanks for pointing that out. What would be a better practice then ? considering that its not a completely new object, and only certain unset fields are to be set ? A void method that mutates the parameter ? I'll google on it meanwhile.. Sep 7 '11 at 12:32
• Yes, in Java that's what you do. The alternative (which depends on your architecture), is to put the method in the JavaBean, so that you call customer.setMissingFields(). And I think it's fine to call it setXX here because it's on the object you want to mutate, and it doesn't have any parameters. If it's a not completely new object in which you need to set certain unset fields I'd name it maybe finishInit(customer) or, if you think it's appropriate, finalise(customer). Or perhaps populateMissingFields(customer) or populateDerivedFields(customer).. Sep 8 '11 at 9:09

I'm a big fan of init() and initX() for those methods that should only be called to get an object into a working state.

• But looking more at your example, I see that the method takes a customer rather than initialising this Sep 5 '11 at 19:39
• Yes, its not a completely new object. Rather an existing object passed on to a method. When its a new object, names like init(), initX(), newXXXX(), createXXX() sound good ofcourse. Sep 7 '11 at 12:36

Looking at what you are actually doing here, assuming that your customer is unprepared before you call the method, why not just create it there and call your method createCustomer