Why do I need FactorySupplier?

Question

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

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 factory is used to hide the implementation of MyServiceImpl if the location or content of MyServiceImpl . But why is there still a factory for my factory (supplier)? I think the likelihood that my factory and my FactorySupplier will change is roughly equal. In addition, I did not find one case where the created factory is created dynamically (I think it would be in the abstract factory template), but it returns only MyServiceFactoryImpl.getInstance() . Is it common practice to implement FactorySupplier? What are the benefits?

Answer 1

I can come up with a couple of examples (some of which are very far-fetched) where this template can be useful. Typically, you have two or more implementations for your services, for example.

• one for production / for testing
• one implementation for access to the database, another for access to file storage
• various implementations for different locales (translations, date and number formatting, etc.)
• one implementation for each type of database that you want to access.

In each of these examples, when starting the application, initialization is required for your FactorySupplier , for example. The FactorySupplier parameter is parameterized using the language or database type and creates the appropriate factories based on these parameters.

If you understand correctly, you do not have such code in your application, and FactorySupplier always returns the same factory type.

Perhaps this was done for an extension program that is not yet needed, but IMHO looks more like guessing which application might be needed in the future, rather than choosing a conscious architecture.

Answer 2

Suppose you have a hierarchy of classes that implement MyServiceIF .

Suppose you have an appropriate factory class hierarchy to create each instance in the original hierarchy.

In this case, MyServiceFactorySupplier may have a registry of available plants, and you may have a call to getMyServiceFactory(parameter) , where the parameter determines which factory will be created (and therefore an instance of this class will be created by the factory).

I do not know if this use case was in your project, but it is a real use case.

Here is a sample code that I have in mind:

 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 an associated hierarchy of classes that are created by a hierarchy of factories. Although I do not have a FactorySupplier class, the base class of the factory hierarchy has a static method BaseFactory.getInstance(parameter) that returns a factory instance that depends on the parameter passed.