Design Question: Creating One Object Type From Multiple Inputs

Question

Hi,
I'm attempting to expand my brain a bit and come up with a more elegant solution to a design I created a few years ago. In simple terms, I have a data object (Request) which can be created based on data in a text file or from data previously persisted in a database record using the Request object and associated DAO. Typically, the text file is initiating a "new" Request object to be persisted, and reading from the database is done to update or view previously submitted Request objects. Note that I have no ability to change the original input method of the text file.
In my original design I basically lumped everything into the Request class using multiple constructors which made for a messy jumble and a very long class. Different parsing routines were needed when data was read from the file vs. reading it from the database. I was considering refactoring the code to use a factory class but this doesn't seem to follow the typical Abstract Factory or Factory Method design patterns. In my design I keep ending up with something like:
public class RequestFactory {
    public Request createRequestFromFile(File file) {...build up the request object...}
    public Request createRequestFromDbRecord(int recordId) {...build up the request object...}
}And I would change the constructor in my Request class to private and remove all of the parsing and construction methods.
Now, I can definitely make this work but I'm not sure I'm really doing much except taking the creation garbage (there's a lot of parsing of multiple-value fields that needs to be done) out of the actual Request class. So my question is basically, do I have a better approach I'm not seeing or is this type of factory "appropriate"? I mean, would someone come along later and look at my code and think I was crazy? I'm still trying to wrap my head around some ways to use factories in my own projects so I'm probably not thinking clearly.
Thanks!
Pablo

Answer 1

Thanks for the feedback. About your suggestions on dealing with the different loading methods, I think that's where I keep getting disconnected, at least as far as using an abstract factory is concerned.
Extending your example code a bit using option one, I would guess I end up with something like this:
public interface RequestFactory {
  Request createRequest(RequestSource source) throws RequestCreationException;
public class DatabaseRequestFactory implements RequestFactory {
  public Request createRequest(RequestSource source) throws RequestCreationException {
    // do some stuff
}The part I can't figure out is how to define the RequestSource (or RequestId in your example). It would seem that if I'm going to define member variables in RequestSource like SourceFile or RecordId it would be just as correct to skip the interface and just use two concrete classes like this:
public class FileRequestFactory {
  Request createRequest(File file) throws RequestCreationException {
    // process file and create request
public class DatabaseRequestFactory {
  public Request createRequest(int recordId) throws RequestCreationException {
    // load record and create request
}I guess where I keep stumbling is a) the value of the interface and b) if I do use an interface, how to have a generic object passed to createRequest() that can refer to either a file location or a record ID. This concept is pretty clear when the creation requirements for each concrete factory are the same, but when the construction uses such disparate data sources for creation I can't seem to wrap my head around the differences.
Your third suggestion is probably the easiest for me to understand but it seems like it would be a bit contrived. In the end it may make the most sense if I am going to go with that type of approach since I still don't really understand how to implement the first two options.
Thanks again for your input.
Pablo
Edited by: Pablo_Vadear on Dec 15, 2009 6:11 AM