I have a simple factory class (FileResources
) with static factory methods providing a default implementation (DefaultFileResource
).
public final class FileResources {
private FileResources() {}
public static FileResource get(Path path) {
return new DefaultFileResource(path);
}
}
The problem with this class is that it is tightly coupled with the default implementation (DefaultFileResource
).
Given a new requirement that classes part of the API (FileResources
) cannot directly depend on classes not part of the API (DefaultFileResource
) I figured that the only solution is inversion of control, either dependency injection or a service provider service locator.
Is it possible to decouple FileResources from the default implementation (DefaultFileResource
)?
As far as I know this is only doable by injecting the dependency into FileResources through a constructor, field or setter method.
The main problem is that the constructor of FileResources is private, furthermore it only has static factory methods.
The alternative is the factory method pattern. There would be an abstract factory (an API class), and there would be concrete factories (non-API classes) that could be even injected to decouple the API and non-API classes.
Either way a dependency container is necessary to handle the wiring.
What do you think? Am I overthinking this?
FileResources
need to be final, and doesget
need to be static? If you make it a plain old java object, it fits in dependency injection very well. But if you're using dependency injection (like Spring) why do you need theFileResources
class at all? Can you just use the Spring bean factory to create your...FileResource
? – sea-rob Mar 11 '14 at 17:45get
,create
, andlocate
methods, each with complex logic to get, create or locate a non-executable data file, and return a FileResource pointing to it. – Vorzard Mar 11 '14 at 19:59