Factory Design-Pattern: (PDFFactory) can you access the db in the getPDF?

[Adrian Burlington]

Hi all,

I have PDFFactory where given a type of EMPLOYEE I construct a pdf.
the code looks like this:

    
	public static PDF getPDF(SecUser secUser, Employee empl) throws BusinessException
	{
		Integer EMPLOYEE_TYPE = empl.getType();
		
		if(EMPLOYEE_TYPE.equals(EmployeeUtil.PROJECT_MANAGER.getCode()))
 			return new ProjectManagerPDF(secUser, empl, "");
		
		if(EMPLOYEE_TYPE.equals(EmployeeUtil.PROGRAMMER.getCode()))
			return new ProgrammerPDF(secUser, empl);
		
		if(EMPLOYEE_TYPE.equals(EmployeeUtil.SYSTEM_ARCHITECT.getCode()))
			return new SysArchitectPDF(secUser, empl); 
		
		throw new BusinessException("NO PDF FORMAT EXISTS FOR THIS TYPE OF EMPLOYEE");
	}
	

So...it appears that the information in the SysArchitectPDF is insufficient! I need to access the DB to get more info (all projects the sys architect has worked on). I wonder if doing this:

  
if(EMPLOYEE_TYPE.equals(EmployeeUtil.SYSTEM_ARCHITECT.getCode()))
{
      //go to db get the relevant information 
     //Map<Long,Projects> map = ....
     return new SysArchitectPDF(secUser, empl, map); 
}
			
  

will not destroy my design. Meaning, is there a better way to do this? I don't want to fetch the information from within the SysArchitectPDF but I need to get it somewhere.

Thanks for any pointers.

[Jimmy Clark]

The purpose of your factory object is to create PDF objects, that is all it should do.

The activities of looking up data in a database should not be handled by the factory object for creating PDF objects.

Don't forget that there is a client object that is using the factory object, so whatever other operations are needed, e.g. populating
the data fields of a PDF Object, then the client object is most likely where this code belongs, or somewhere else in the application.

public final PDFObject getPDFObject(SecUser secUser, Employee empl) throws BusinessException       {   

        PDFObject  o;

        Integer type = empl.getType();   
           
        if (type.equals(EmployeeUtil.PROJECT_MANAGER_CODE))  {
  
            o = new ProjectManagerPDFObjectImpl(secUser, empl); 

        } else if (type.equals(EmployeeUtil.PROGRAMMER_CODE)) {   

            o = new ProgrammerPDFObjectImpl(secUser, empl);   
       
        } else if (type.equals(EmployeeUtil.SYSTEM_ARCHITECT_CODE))  {
 
            o = new SysArchitectPDFObjectImpl(secUser, empl);    
        }

        if (o == null) {
    
            throw new BusinessException("No PDF format exists for this type of employee ( " + empl.getID() + ")");   
        }

        return o;
    }   

One method = one return statement leads to cleaner, understandable code...

[Jelle Klap]

Henry Pinkerton wrote:
One method = one return statement leads to cleaner, understandable code...

That's debatable.

[Vlad Varnica]

Here is the sequence diagram of the code of Adrian Burlington

[Vlad Varnica]

Here is the reverse communication and sequence diagram of the code of Henry Pinkerton

[Adrian Burlington]

Thank you all for your input. Yes, I agree it should not be in the Factory.

Also, nice diagrams Vald, can you tell us how you did that?

Thanks!

[Vlad Varnica]

I use Eclipse 3.5 SR2 and have copied your code in a new project. I then reverse it with an Eclipse modeling tool.