Является ли передача интерфейса AsyncTask хорошей практикой

Question

У меня есть класс интерфейса

public interface AsyncTaskExecuteCommand {
public Object executeCommand(String jsonLocation) throws IOException,JSONException;
}

И у меня есть HashMap, в котором хранятся экземпляры этого интерфейса

public static HashMap<String,AsyncTaskExecuteCommand> executeCommandHashMap

executeCommandHashMap.put(COMMAND_CORE_FIELD_FETCH, new AsyncTaskExecuteCommand() {
        @Override
        public Object executeCommand(String jsonLocation) throws IOException, JSONException{
                           //return some thing
        }
    });

executeCommandHashMap.put(COMMAND_REGISTER_FIELD_FETCH, new AsyncTaskExecuteCommand() {
        @Override
        public Object executeCommand(String jsonLocation) throws IOException,
                JSONException {
                          //return some thing
        }
    });

И мой AsyncTask с именем GeneralAsyncTask включает в себя

doInBackground(){

 AsyncTaskExecuteCommand asyncTaskExecuteCommand = executeCommandHashMap.get(params[0]);
 return asyncTaskExecuteCommand.executeCommand(params[1]);
}

И этот AsyncTask называется

new GeneralAsyncTask().execute(COMMAND_REGISTER_FIELD_FETCH,"http://something");

Я сделал это, потому что общая структура моего AsyncTask остается прежней, то есть он выполняет некоторое выполнение метода и возвращает некоторое значение. Только тип выполнения метода и возвращаемое значение будутбыть другим. Если я не буду реализовывать передачу интерфейса к асинхронной задаче, я в конечном итоге создаю множество классов AsyncTask.Итак, этот метод хорош для решения моего сценария?

Answer 1

Похоже, много сложностей.Есть ли причина, по которой вы просто не используете анонимный класс:

new AsyncTask<String, Void, Object>() {
    @Override
    protected Object doInBackground(String... url) {
        //return some thing
    }
    protected void onPostExecute(Object result) {
        // do something with result
    }
}.execute("http://something");

Answer 2

Интерфейс имеет смысл, если вы собираетесь кодировать реализации и иметь их как отдельные классы в некотором пакете.Это улучшает читабельность.Если цель не состоит в том, чтобы писать AsynkTask каждый раз, потому что он имеет некоторые общие части, но изменяется только doInBackground, то я бы расширил AsyncTask до конкретного универсального класса, принимающего интерфейс GENERIC, такой как этот:

    public interface MyTask<T,R> {
        R doInBackground(T... param);
    }

Класс будет выглядеть примерно так (не проверено):

    public class MyAsyncTask<T, P, R> extends AsyncTask<T, P, R> {
        private MyTask<T,R> task;

        public MyAsyncTask(MyTask<T,R> todo){
            task = todo;
        }

        protected R doInBackground(T... params) {
            if(task != null){
                return task.doInBackground(params);
            } else {
                return null;
            }
        }

        //Other AsyncTask mandatory methods implemented here. 

    }

Или, если у вас все в порядке без обобщений, тогда сделайте интерфейс и подкласс AsyncTask не универсальными.В любом случае, я бы кодировал класс (ы) задач и реализации команд, помещал их в пакет, делал их одиночными (или имел публичные ссылки в каком-то главном классе) и избавлялся от карты.