Java - Something similar to Abstract Factory? 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).

/** 
 * 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();
                return bitbucketTools;
            case FILE:
                if (localFileTools == null)
                    localFileTools = new LocalFileTools();
                return localFileTools;
            case FOLDER:
                if (localFolderTools == null)
                    localFolderTools = new LocalFolderTools();
                return localFolderTools;
            default:
                throw new NotImplementedException("Repository.TYPE = " + repo.getType());
        }
    }
}


Then I can take a repository from the map and download it like:

Repository repo = getRepo();
Path output = Paths.get("C:\\out")
AbstractRepositoryTools.downloadZip(repo, "develop", output);


It works but... 


Does this code smell?
If yes, how to improve it?
If no, is there a name for such architecture pattern?
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 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&lt;Repository.Type, AbstractRepositoryTools&gt; cache =
        new EnumMap&lt;&gt;(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 final

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 Facade