patternjavaModerate
Java - Something similar to Abstract Factory?
Viewed 0 times
abstractfactoryjavasimilarsomething
Problem
I have many repositories stored in a map. User chooses some of them and then a downloading begins. Repository may be one of 4 types (see code below).
There are package-private classes that implement
```
/**
* Resolver of a RepositoryTools implementation (with caching)
*/
class Resolver {
// cache
private static volatile BitbucketTools bitbucketTools = null;
private static volatile GitTools gitTools = null;
private static volatile LocalFileTools localFileTools = null;
private static volatile LocalFolderTools localFolderTools = null;
public static synchronized AbstractRepositoryTools getToolsFor(Repository repo) {
switch (repo.getType()) {
case GITHUB:
if (gitTools == null)
gitTools = new GitTools();
return gitTools;
case BITBUCKET:
if (bitbucketTools == null)
bitbucketTools = new BitbucketTools();
/**
* Data class that stores settings of a connection to repository.
* Lombok's annotations are used to generate some methods.
*/
@Getter
@EqualsAndHashCode
public class Repository {
public enum Type {
FILE, FOLDER, GITHUB, BITBUCKET
}
private Type type;
private String username;
private char[] password;
/*...*/
}
/**
* A class that contains common stuff for all repository tools (such as connection to remote repository, download, logging, etc.)
*/
public abstract class AbstractRepositoryTools {
/**
* This method is implemented in child classes and actually it does the job.
*/
protected abstract void doDownloadZip(Repository repo, String branch, Path saveTo);
public static void downloadZip(Repository repo, String branch, Path saveTo) {
AbstractRepositoryTools tools = Resolver.getToolsFor(repo);
tools.doDownloadZip(repo, branch, saveTo);
}
}There are package-private classes that implement
AbstractRepositoryTools for GitHub, BitBucket, and local repositories (folder or zip file).```
/**
* Resolver of a RepositoryTools implementation (with caching)
*/
class Resolver {
// cache
private static volatile BitbucketTools bitbucketTools = null;
private static volatile GitTools gitTools = null;
private static volatile LocalFileTools localFileTools = null;
private static volatile LocalFolderTools localFolderTools = null;
public static synchronized AbstractRepositoryTools getToolsFor(Repository repo) {
switch (repo.getType()) {
case GITHUB:
if (gitTools == null)
gitTools = new GitTools();
return gitTools;
case BITBUCKET:
if (bitbucketTools == null)
bitbucketTools = new BitbucketTools();
Solution
A few points about your resolver.
Since you're using an enum to specify the repository's Type and resolve the tools depending on that type, an
Also caching objects that have virtually no creation cost seems overkill to me. You can just eagerly initialize the objects and then don't even have to care about multithreading problems:
Additionally I wouldn't call the class
You can simplify the resolver call by only giving it the type of the repo (since that's the only thing necessary). Furthermore I would extract the
Other than that your code is very clear and simple. I assume the javadoc comments are only explanatory notes for reviewers, and that you excluded the actual javadoc.
And since you asked about the name of the pattern... This is a
Since you're using an enum to specify the repository's Type and resolve the tools depending on that type, an
EnumMap seems to be the simplest solution to resolving the specific tool implementation necessary.Also caching objects that have virtually no creation cost seems overkill to me. You can just eagerly initialize the objects and then don't even have to care about multithreading problems:
class Resolver {
private static final Map cache =
new EnumMap<>(Repository.Type.class);
static {
cache.put(GITHUB, new GitTools());
cache.put(FILE, new LocalFileTools());
cache.put(FOLDER, new LocalFolderTools());
cache.put(BITBUCKET, new BitbucketTools());
}
public static AbstractRepositoryTools getToolsFor(Repository repo) {
if (cache.containsKey(repo.getType()) {
return cache.get(repo.getType());
}
throw new NotImplementedException("Repository.TYPE = " + repo.getType());
}
}Additionally I wouldn't call the class
AbstractRepositoryTools, but just RepositoryTools. You can simplify the resolver call by only giving it the type of the repo (since that's the only thing necessary). Furthermore I would extract the
doDownloadZip into a separate interface and then seal the RepositoryTools class by declaring it finalOther than that your code is very clear and simple. I assume the javadoc comments are only explanatory notes for reviewers, and that you excluded the actual javadoc.
And since you asked about the name of the pattern... This is a
FacadeCode Snippets
class Resolver {
private static final Map<Repository.Type, AbstractRepositoryTools> cache =
new EnumMap<>(Repository.Type.class);
static {
cache.put(GITHUB, new GitTools());
cache.put(FILE, new LocalFileTools());
cache.put(FOLDER, new LocalFolderTools());
cache.put(BITBUCKET, new BitbucketTools());
}
public static AbstractRepositoryTools getToolsFor(Repository repo) {
if (cache.containsKey(repo.getType()) {
return cache.get(repo.getType());
}
throw new NotImplementedException("Repository.TYPE = " + repo.getType());
}
}Context
StackExchange Code Review Q#106336, answer score: 10
Revisions (0)
No revisions yet.