Why do I need a FactorySupplier?

Question

In the project I'm working on (not my project, just working on it), there are many structures like this:

project.priv.logic.MyServiceImpl.java
project.priv.service.MyServiceFactoryImpl.java

project.pub.logic.MyServiceIF.java
project.pub.service.MyServiceFactoryIF.java
project.pub.service.MyServiceFactorySupplier.java

And the Service is called like this:

MyServiceFactorySupplier.getMyServiceFactory().getMyService()

I understand that a factory is used to hide the implementation of MyServiceImpl if the location or content of MyServiceImpl changes. But why is there another factory for my factory (the supplier)? I think the probability of my Factory and my FactorySupplier to change is roughly equal. Additionally I have not found one case, where the created factory is created dynamically (I think this would be the case in the Abstract Factory Pattern) but only returns MyServiceFactoryImpl.getInstance(). Is it common practice to implement a FactorySupplier? What are the benefits?

Towering

Answer 1

I can think of a couple of examples (some of the quite contrived) where this pattern may be useful. Generally, you have two or more implementations for your Services e.g.

• one for production use / one for testing
• one implementation for services accessing a database, another one for accessing a file base storage
• different implementations for different locales (translations, formatting of dates and numbers etc)
• one implementation for each type of database you want to access

In each of these examples, an initialization for your FactorySupplier is needed at startup of the application, e.g. the FactorySupplier is parametrized with the locale or the database type and produces the respective factories based in these parameters.

If I understand you correctly, you don't have any kind of this code in your application, and the FactorySupplier always returns the same kind of factory.

Maybe this was done to program for extensibility that was not needed yet, but IMHO this looks rather like guessing what the application might need at some time in the future than like a conscious architecture choice.

Forsake

Answer 2

Suppose you have a hierarchy of classes implementing MyServiceIF.

Suppose you have a matching hierarchy of factory classes to create each of the instances in the original hierarchy.

In that case, MyServiceFactorySupplier could have a registry of available factories, and you might have a call to getMyServiceFactory(parameter), where the parameter determines which factory will be instantiated (and therefore an instance of which class would be created by the factory).

I don't know if that's the use case in your project, but it's a valid use case.

Here's a code sample of what I mean :

public class MyServiceImpl implements MyServiceIF 
{
....
}

public class MyServiceImpl2 implements MyServiceIF
{
....
}

public class MyServiceFactoryImpl implements MyServiceFactoryIF
{
    ....
    public MyServiceIF getMyService ()
    {
        return new MyServiceImpl ();
    }
    ....
}

public class MyServiceFactoryImpl2 implements MyServiceFactoryIF
{
    ....
    public MyServiceIF getMyService ()
    {
        return new MyServiceImpl2 ();
    }
    ....
}

public class MyServiceFactorySupplier
{
    ....
    public static MyServiceFactoryIF getMyServiceFactory()
    {
        return new MyServiceFactoryImpl (); // default factory
    }

    public static MyServiceFactoryIF getMyServiceFactory(String type)
    {
        Class serviceClass = _registry.get(type);
        if (serviceClass != null) {
            return serviceClass.newInstance ();
        } else {
            return getMyServiceFactory(); // default factory
        }
    }
    ....
}

I have a related hierarchy of classes that are instantiated by a hierarchy of factories. While I don't have a FactorySupplier class, I have in the base class of the factories hierarchy a static method BaseFactory.getInstance(parameter), which returns a factory instance that depends on the passed parameter.

Deuterogamy