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?

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.