Factory Pattern w/ Delegates

I've been focusing some of my efforts on rounding out a lightweight IoC Factory. The implementation is fairly simple, you have a Factory object that has Delegates, each Delegate represents a type that can be created by the Factory. The Factory itself only has few methods on it:

public interface UserDao { ... }



public class UserDaoImpl implements UserDao { ... }



public class User { .... }



public class UserSaveAction {

    public UserSaveAction(UserDao dao) { ... }

    public UserSaveAction(UserDao dao, User user) { ... }

    // getter/setters

    public String save() { ... }

}





DefaultFactory f = new DefaultFactory();

f.register(new SingletonDelegate(UserDaoImpl.class));

f.register(UserSaveAction.DELEGATE); // register(Delegate)



...

// builds a UserSaveAction with new User

UserSaveAction newUser = f.get(UserSaveAction.class);  

newUser.setFirstName("John");

newUser.setLastName("Doe");

newUser.save(); 



// refetch that user, generics removes the need for casting

User user = f.get(UserDao.class).getByFirstName("John");



// get(Class,Object... params) (variable arguments)

UserSaveAction updateUser = f.get(UserSaveAction.class, user);

updateUser.setFirstName("Jacob");

updateUser.setLastName("Hookom");

updateUser.save();

In the above example, we've registered the UserDaoImpl in a Singleton Delegate. The Delegate lookup within the Factory is smart enough to return the UserDaoImpl anytime a developer requests UserDao (it's interface).

One thing you'll notice is that the 'get' method uses variable arguments, just like the new System.out.printf(...) method. This allows the Delegate to take that input and automatically uses it during instantiation. e.g., UserSaveAction has a 2 constructors, calling Factory.get(UserSaveAction.class) didn't take any parameters, so it will create a UserSaveAction with whatever other Types are in the Factory (UserDaoImpl). In the second case of updating a user, the example had taken in a user-- get(UserSaveAction.class, user). This caused the Factory to find a constructor that also took in a User object.

In order to speed up performance, lets say this Action was used on the web and we wanted to squeak out a little more performance, UserSaveAction declares it's own public Delegate to be registered. This allowed UserSaveAction to control how it was going to be created based on input.

public static final UserSaveDelegate DELEGATE =

                           new UserSaveDelegate();



public static class UserSaveDelegate

    implements Delegate {



    public UserSaveAction create(Factory f)

        throws ActualizationException {

        return new UserSaveAction(f.get(UserDao.class));

    }



    public UserSaveAction create(Factory f, Object[] p)

        throws ActualizationException {

        return new UserSaveAction((User) p[0],

                                  f.get(UserDao.class));

    }



    public Class getType() {

        return UserSaveAction.class;

    }

}

By creating it's own delegate, my performance tests performed only a fraction slower than wiring the components together directly.

I would now like to add "listener" behavior to creation. Allowing additional components to be wired together in ways other than constructor injection-- such as annotations. I'm open to suggestions on how/where the listener behavior should occur, if it should be assigned on a per Delegate level or at the Factory level. Also, since the Factory doesn't dictate lifecycles at all, listeners at the Factory level would be notified whenever an object is "grabbed", not knowing if it was just created or if it's the 4th time it's been grabbed.