tags:

views:

103

answers:

3

I'm doing a java application.

This are my files so far:

Person Interface.

has a setName(String aName) method

PersonImpl

Implementation of Person Interface.

PersonFactory Interface

has a createPerson()

PersonFactoryImpl

Implementation of PersonFactory Interface.

The thing is I was willing to add a method getAll() that returns a Collection of Persons and I am not sure where to place it.

I was thinking of adding it as an static method to PersonImpl or to PersonFactoryImpl, but I am not sure.

Which is the best way?

Thanks for reading!

+3  A: 

The logical way would be to add it as a static method to the PersonFactory. That is the class which generates your Person objects, and if it keeps references to all generated objects, it should be able to answer your getAll() API.

Obviously, it is not reasonable for each Person object to be aware of other similar objects, thus this method does not belong there.

EDIT: Given the fact that they reside on a database, it might be wise to decouple the PersonFactory (which job is to create Person objects), from a PersonRepository which will be actually accessing the database (or whatever persistency you have) and returning Person objects.

It would seem awkward to me that the same class is responsible both for creating objects as well as fetching them from a database. That being said, if your application demands this tight-coupling, it might be acceptable.

Yuval A
Actually they are saved on a db. the getAll() will get them from there. Don't know if this changes your answer.
Macarse
Why make it static?
Steve Kuo
Since factories are *usually* never instantiated...
Yuval A
+3  A: 

If another implementation of PersonFactory is provided, should it also need to provide a #getAll? If so, it belongs on the interface... and then it can't be a static method in Java.

Given that, is it a function of your PersonFactory or should there be an abstraction for your storage mechanism as well? If so, a PersonRepository interface whose implementations accept a PersonFactory, and provides a natural home for getAll-type functionality seems more appropriate. If not, then as a member of the concrete PersonFactory could be appropriate enough...

Tetsujin no Oni
Yes, if there is another impl of PersonFactory it should provide #getAll. To add it to the interface I can make it not static, but doesn't look good.Please, could you explain better what you mean with PersonRepository?
Macarse
Static mutable state is evil - it doesn't make sense, and for bonus points it's difficult to test, is non-obviously multi-threaded and is not secure. For repository - google for the pattern, or Martin Fowler's Patterns of Enterprise Application Architecture has it, IIRC.
Tom Hawtin - tackline
BTW: +1 for repository. Probably doesn't need to be an interface though.
Tom Hawtin - tackline
For better, not-database-coupled, unit testing, my implementation pattern is that the Repository must be an interface. YMMV.
Tetsujin no Oni
A: 

The factory is responsible managing instances of Persons, so that is the correct place to put it. Furthermore, it should be non-static just as createPerson() is.

Steve Kuo