factory question

I have this interface:

publicinterface

UserInfo{

public StringgetUid();

public StringgetKps();

public StringgetName();

public List<String> getRoles();

public StringgetMainRole();

public StringgetClientHost();

publicfloatgetBalance();

public List<ChargeKey>getCharges();

public List<PrintHistory>getHistory();

}

I have a UserFactory class that has 2 methods, getParameterUser() and getLoginUser(), both return UserInfo by doing UserImpl user =new UserImpl(uid, utils);

Where UserImpl implements UserInfo, and they return that. The utils parameter is a utility class that has several utility methods that do things like ldap lookups and other stuff to fill in the first 5 fields (excluding uid which is passed in), uid, kps, name, roles, mainRole, clientHost. The balance, charges, and history fields are filled in by calls to data access object methods. There are separate DAOs for each one (balance, charges, and history).

I would like to keep instances of the UserInfo fairly lightweight and it's immutable so it has only getters, no setters.

I couldn't see a way to set the balance, charges, and history fields from within the UserImpl other than passing in the DAOs, or by having setters for them and injecting them, but then it's either ugly with a lot of parameters to its constructor or it has references to the DAOs that it only uses once to set itself up.

The UserFactory, UserInfo, and UserImpl are the only classes in the package xyz.user so remembering that in Effective Java he said it's ok to have fields that are package private I made balance, charges, and history package private and they're set in the UserFactory getLoginUser and getParameterUser methods.final UserImpl user =new UserImpl(uid, utils);

/*

* Set the package-private fields.

*/

user.charges = chargeHistoryDao.get(uid);

user.balance = balanceDao.getBalance(user.getKps());

user.history = printHistoryDao.getHistory(user.getKps());

return(user);

But now I'm wondering why bother doing any setup in the UserImpl's constructor. Why not just make all of its fields package private and set them all up in the factory? So that all UserImpl has is fields and getter methods and no code in its constructor.

Does this make sense? Good or bad idea?

[3029 byte] By [LumpyNosea] at [2007-10-2 17:44:54]
# 1

I figured out my problem while folding my laundry. Sometimes I start out doing things the Wrong Way and then it takes me awhile to realize it and disengage from it. The factory method should collect all of the data and then call the UserImpl constructor with all of it. Looks ugly having all those parameters to the constructor but since it's hidden inside of the factory it'll do.

LumpyNosea at 2007-7-13 19:02:39 > top of Java-index,Other Topics,Patterns & OO Design...
# 2

That sounds right to me. If you have too many parameters, collect them into an object (or several). The reason you should prefer constructor's to Javabean setters (even if they are package-private rather than public methods) is the following:

> Immutable objects are easier to understand, code and test

Make as many variables (instance, method signature, constructor signature) final as possible. This will often-times show you an error at compile-time rather than run-time. Now, don't take this to an extreme. A system made of 100% immutable objects is probably conceptually possible, but not advisable.

Take each variable as a separate case. Should I really provide a setter for a primary key? Should I really provide a setter for a type-safe enum? Should I really provide a setter to alter city/state/zip separately or all together (or better yet, simply accept an Address object)? Etc.

- Saish

Saisha at 2007-7-13 19:02:39 > top of Java-index,Other Topics,Patterns & OO Design...