How to package Factories in Java

Question

Hi Guys,

I was wondering how to package the factories I have in my application. Should the Factory be in the same pacakage as the classes that use it, in the same package as the objects it creates or in its own package?

Thanks for yout time and feedback

Answer 1

Usually factories are in the same package as the objects they create; after all their purpose is to create those objects. Usually they are not in a separate package (there is no reason for that). Also having the factory be in the same package as the objects they create allows you to exploit package visibility.

Answer 2

I like to put the factory in the package it is creating objects for, naming is key here, if naming is clear and transparent it will help maintenance effort down the line.

For example an action factory could be structured as:

• package org.program.actions
• interface org.program.actions.Action
• enum org.program.actions.ActionTypes
• factory org.program.actions.ActionFactory (or .ActionManager)
• action implementation classes org.program.actions.LogAction, etc.

Following patterns like this throughout projects help project members to find classes where they actually are located in projects they haven't been involved in before.

Answer 3

That wholly depends on the way you're intending to use said factories. Sometimes it makes sense to put a factory in its own package.

You might for example have an interface, foo.bar.ui.Interface. You want to have different implementations of that interface, one for AWT, one for Swing, one for the console, etc. Then it would be more appropriate to create a foo.bar.ui.swing.SwingInterfaceFactory that creates a foo.bar.ui.swing.SwingInterface. The factory for the foo.bar.ui.awt.AWTInterface would then reside in foo.bar.ui.awt.AWTInterfaceFactory.

Point is, there is no always-follow-this rule. Use whatever is appropriate for your problem.

Answer 4

Bombe, in your example you are still putting the Factory in the same package as the objects they create :-) Which is the right way to do it and what everyone else has been saying!

Answer 5

The unit of reuse is the unit of release. This means there shouldn't be coupling across packages, as the package is generally the lowest granularity of release. When you organize a package, imagine yourself saying, "here's everything you need to use these classes."

Answer 6

why not. make it as close as possible if there is no other objections. actually why not

public interface Toy
{
    static class Factory
    {
        public static final Toy make() { ... }
    }
}

Toy toy = Toy.Factory.make();

HA!

but make() shouldn't statically depend on subclasses of Toy, that would be bad. it can do some dynamic magic, depends on your factory strategy.

Answer 7

The whole point of a Factory is to have a configurable way to create implementation instances for interfaces. The convention to have the factory in the same package as the implementation classes it provides adds a completely unnecessary restriction you're unlikely to meet in the future. Also if the implementation returned is not the same across all contexts, it makes even less sense to have it in the same package.

For example, imagine a service lookup factory that is shared between the client and server part of an application, which returns a client side implementation (which resides in a client-only package) on the client, and a server side implementation (in a server-only package) when called from within the server's runtime.

Your factory may even be configurable (we do this by having a XML file which defines which implementation class to return for which interface), so the implementation classes can easily be switched, or different mappings can be used for different contexts. For example, when unit testing we use a configuration which returns mockup implementations for the interfaces (do be able to do unit tests that are not integration tests), and it would make no sense at all to require those mockup implementations to be in the same package as the factory, as they're part of the testing code rather than the runtime code.

My recommendation:

• Don't add any package restrictions on the implmentation classes, as you don't know which implementations are used in the future, or in different contexts.
• The interfaces may be in the same package, but this restriction is also unnecessary and only makes the configuration rigid.
• Configurable factories (such as a service lookup) can be reused and shared across projects when the interface/implementation mapping isn't hardcoded. This point alone justifies having the factory separated from both the interfaces and the implementation classes.