String [] args vs (String... Args)


9

При программировании для Android, всякий раз, когда я использую AsyncTask, метод doInBackground выглядит следующим образом.

 protected String doInBackground(String... args)

Но при использовании аргументов в любом месте этого блока я могу получить к ним доступ, как к обычному массиву String, например, в моей программе

        @Override
    protected String doInBackground(String... args)
    {
        String details = "";
        try
        {
            details = facade.getRecipeDetails(args[0]);
        }
        catch(Exception ex)
        {
            ex.printStackTrace();
        }
        return details;
    }

Что отлично работает, и у меня нет проблем с этим справиться. Но мне интересно, почему они используют (String ... Args) вместо обычного массива Strings. Это просто потому, что в вызывающем методе вы можете просто написать что-то вроде:

 new AsyncHandler.execute("argument1","argument2","argument3",...)  

вместо создания нового массива для передачи аргументов? Хотя мы могли бы написать

new AsyncHandler().execute(new String[]{"Argument1","Argument2"});

что немного более многословно.

Являются ли (String ...) и String [] синонимичными в том, как они работают, но передача аргументов проще с помощью первого, потому что нет необходимости создавать массив? Насколько я могу судить, первый также переводится в массив строк в фоновом режиме, так что они оба будут компилироваться в один и тот же код, и это просто «синтаксический сахар»?


(String ...)означает, что вы можете добавить столько Stringпараметров, сколько хотите, String[]это один параметр, который представляет собой массив строк. (String ...)зависит от первого параметра AsyncTask, это не всегда String.
FaizanRabbani

@FaizanRabbani за исключением того, что вы также можете назвать a, String...как будто этоString[]
трещотка урод

@ratchetfreak Да, он может действовать как String[], но давайте предположим, что это было по умолчанию String[]. Было бы довольно проблематично использовать другой Stringпараметр в массиве. Вместо этого они дали гибкость в использовании (String ...).
FaizanRabbani

@FaizanRabbani Я знаю, что это не всегда String, это просто пример =). То же самое относится и к логическим значениям ... или другим вещам, но мне понравилось использовать String из-за основных (аргументов String []), с которыми мы знакомы. И вы сказали: «Вы можете передать столько строк, сколько хотите», ну, вы можете передать довольно много строк с помощью массива. Мне все еще кажется, что вы можете добиться того же с массивами, хотя это менее читабельно и больше хлопот. (Передача массива массивов, например, немного снизит читаемость). Правильно ли, что это в основном для удобства чтения? (спасибо уже кстати)
Дилан Мееус

@FaizanRabbani - это просто new String[]{...}конвертировать (это то, что на самом деле происходит, когда вы используете String...)
трещотка урод

Ответы:


15

(String ...)является массивом параметров типа String, где as String[]является единственным параметром .

Теперь здесь String[]можно полностью выполнить ту же цель, но (String ...)обеспечивает большую удобочитаемость и простоту использования.

Он также предоставляет возможность, с помощью которой мы можем передавать несколько массивов, Stringа не один String[].


1
В то время как String[]может быть передано в метод, принимающий String...в качестве параметра, два String[]s не могут. Здесь не существует неявной конкатенации массивов.

5

Особенностью String [] против String ... является то, что "String ..." не обязательно должен быть частью вызова.

public void test(String... args){ 
   if(args.length > 0){
      for( String text : args){
         System.out.println(text);
      }
   }else{
      System.out.println("No args defined.");
   }
}

public void callerTest(){
     test();
     System.out.println();

     test("tree");
     System.out.println();

     test("dog", "cat", "pigeon");
}

Тогда, если вы позвоните, callerTest();вывод будет:

No args defined.

tree

dog
cat
pigeon
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.