Одним из свойств этого подхода, который не был указан до сих пор, является то, что, поскольку вы создаете внутренние классы, весь содержащийся класс захватывается в своей области. Это означает, что до тех пор, пока ваш Set жив, он сохранит указатель на содержащий экземпляр (this$0) и сохранит его от сбора мусора, что может быть проблемой.

Это и тот факт, что новый класс создается в первую очередь, даже если обычный HashSet будет работать просто отлично (или даже лучше), заставляет меня не хотеть использовать эту конструкцию (хотя я действительно долго синтаксический сахар).

Второй вопрос: новый HashSet должен быть "this", используемый в инициализаторе экземпляра... может ли кто-нибудь пролить свет на механизм? Я бы наивно ожидал, что "this" ссылается на инициализацию объекта "ароматы".

Это то, как работают внутренние классы. Они получают свой собственный this, но у них также есть указатели на родительский экземпляр, так что вы также можете вызывать методы для содержащего объекта. В случае конфликта именования внутренний класс (в вашем случае HashSet) имеет приоритет, но вы можете префикс "this" с именем класса, чтобы получить внешний метод.

public class Test {

    public void add(Object o) {
    }

    public Set<String> makeSet() {
        return new HashSet<String>() {
            {
              add("hello"); // HashSet
              Test.this.add("hello"); // outer instance 
            }
        };
    }
}

Чтобы быть понятным в создании анонимного подкласса, вы также можете определить методы там. Например, переопределить HashSet.add()

    public Set<String> makeSet() {
        return new HashSet<String>() {
            {
              add("hello"); // not HashSet anymore ...
            }

            @Override
            boolean add(String s){

            }

        };
    }

Каждый раз, когда кто-то использует двойную привязку, котенка убивают.

Помимо синтаксиса, довольно необычного и не очень идиоматического (вкус, конечно, дискуссионный), вы без необходимости создаете две существенные проблемы в своем приложении, которые Я недавно недавно рассказал о более подробных сообщениях.

1. Вы создаете слишком много анонимных классов

Каждый раз, когда вы используете инициализацию двойной скобки, создается новый класс. Например. этот пример:

Map source = new HashMap(){{
    put("firstName", "John");
    put("lastName", "Smith");
    put("organizations", new HashMap(){{
        put("0", new HashMap(){{
            put("id", "1234");
        }});
        put("abc", new HashMap(){{
            put("id", "5678");
        }});
    }});
}};

... создаст эти классы:

Test$1$1$1.class
Test$1$1$2.class
Test$1$1.class
Test$1.class
Test.class

Это довольно немного накладных расходов для вашего загрузчика классов - ни за что! Конечно, это не займет много времени для инициализации, если вы это сделаете один раз. Но если вы делаете это 20 000 раз по всему вашему корпоративному приложению... все, что куча памяти только для немного "синтаксического сахара"?

2. Вы потенциально создаете утечку памяти!

Если вы берете приведенный выше код и возвращаете эту карту из метода, вызывающие его методы могут быть ничего не подозревающими на очень тяжелых ресурсах, которые не могут быть собраны в мусор. Рассмотрим следующий пример:

public class ReallyHeavyObject {

    // Just to illustrate...
    private int[] tonsOfValues;
    private Resource[] tonsOfResources;

    // This method almost does nothing
    public Map quickHarmlessMethod() {
        Map source = new HashMap(){{
            put("firstName", "John");
            put("lastName", "Smith");
            put("organizations", new HashMap(){{
                put("0", new HashMap(){{
                    put("id", "1234");
                }});
                put("abc", new HashMap(){{
                    put("id", "5678");
                }});
            }});
        }};

        return source;
    }
}

Возвращаемый Map теперь будет содержать ссылку на прилагаемый экземпляр ReallyHeavyObject. Вероятно, вы не хотите рисковать тем, что:

_{Изображение из http://blog.jooq.org/2014/12/08/dont-be-clever-the-double-curly-braces-anti-pattern/}

3. Вы можете притворяться, что у Java есть литералы по картам

Чтобы ответить на ваш реальный вопрос, люди использовали этот синтаксис, чтобы притворяться, что Java имеет что-то вроде картографических литералов, похожих на существующие литералы массивов:

String[] array = { "John", "Doe" };
Map map = new HashMap() {{ put("John", "Doe"); }};

Некоторые люди могут найти это синтаксически стимулирующее.

Взяв следующий тестовый класс:

public class Test {
  public void test() {
    Set<String> flavors = new HashSet<String>() {{
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
    }};
  }
}

а затем декомпилировать файл класса, я вижу:

public class Test {
  public void test() {
    java.util.Set flavors = new HashSet() {

      final Test this$0;

      {
        this$0 = Test.this;
        super();
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
      }
    };
  }
}

Это не выглядит ужасно неэффективным для меня. Если бы я беспокоился о производительности для чего-то подобного, я бы это прокомментировал. На ваш вопроС# 2 отвечает приведенный выше код: вы находитесь внутри неявного конструктора (и инициализатора экземпляра) для вашего внутреннего класса, поэтому "this" относится к этому внутреннему классу.

Да, этот синтаксис неясен, но комментарий может прояснить неявное использование синтаксиса. Чтобы прояснить синтаксис, большинство людей знакомы со статическим блоком инициализатора (JLS 8.7 Static Initializers):

public class Sample1 {
    private static final String someVar;
    static {
        String temp = null;
        ..... // block of code setting temp
        someVar = temp;
    }
}

Вы также можете использовать аналогичный синтаксис (без слова "static" ) для использования конструктора (JLS 8.6 Instance Initializers), хотя я никогда не видел этого, используемого в производственном коде. Это гораздо менее известно.

public class Sample2 {
    private final String someVar;

    // This is an instance initializer
    {
        String temp = null;
        ..... // block of code setting temp
        someVar = temp;
    }
}

Если у вас нет конструктора по умолчанию, тогда блок кода между { и } превращается в конструктор компилятором. Имея это в виду, разгадайте код двойной скобки:

public void test() {
  Set<String> flavors = new HashSet<String>() {
      {
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
      }
  };
}

Блок кода между внутренними скобками превращается в конструктор компилятором. Внешние самые фигурные скобки ограничивают анонимный внутренний класс. Чтобы сделать это, последний шаг сделать все не анонимным:

public void test() {
  Set<String> flavors = new MyHashSet();
}

class MyHashSet extends HashSet<String>() {
    public MyHashSet() {
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
    }
}

В целях инициализации я бы сказал, что нет накладных расходов (или настолько малых, что его можно пренебречь). Однако каждое использование flavors будет идти не против HashSet, а вместо этого MyHashSet. Вероятно, это небольшое (и, возможно, незначительное) накладные расходы. Но опять же, прежде чем я волновался об этом, я бы прокомментировал его.

Опять же, на ваш вопроС# 2, приведенный выше код является логическим и явным эквивалентом инициализации двойной привязки, и это делает очевидным, где "this" относится к внутреннему классу, который расширяет HashSet.

Если у вас есть вопросы о деталях инициализаторов экземпляра, ознакомьтесь с деталями в документации JLS.

склонность к утечке

Я решил перезвонить. Эффект производительности включает в себя: дисковая операция + unzip (для jar), проверка класса, пространство perm-gen (для Sun Hotspot JVM). Однако, самое худшее: он просачивается. Вы не можете просто вернуться.

Set<String> getFlavors(){
  return Collections.unmodifiableSet(flavors)
}

Итак, если набор выходит в любую другую часть, загруженную другим загрузчиком классов, и там хранится ссылка, будет уничтожено все дерево классов + загрузчик классов. Чтобы этого избежать, необходима копия в HashMap, new LinkedHashSet(new ArrayList(){{add("xxx);add("yyy");}}). Не так мило. Я сам не использую эту идиому, вместо этого она похожа на new LinkedHashSet(Arrays.asList("xxx","YYY"));

Загрузка многих классов может добавить к началу несколько миллисекунд. Если запуск не столь критичен, и вы смотрите на эффективность классов после запуска, нет никакой разницы.

package vanilla.java.perfeg.doublebracket;

import java.util.*;

/**
 * @author plawrey
 */
public class DoubleBracketMain {
    public static void main(String... args) {
        final List<String> list1 = new ArrayList<String>() {
            {
                add("Hello");
                add("World");
                add("!!!");
            }
        };
        List<String> list2 = new ArrayList<String>(list1);
        Set<String> set1 = new LinkedHashSet<String>() {
            {
                addAll(list1);
            }
        };
        Set<String> set2 = new LinkedHashSet<String>();
        set2.addAll(list1);
        Map<Integer, String> map1 = new LinkedHashMap<Integer, String>() {
            {
                put(1, "one");
                put(2, "two");
                put(3, "three");
            }
        };
        Map<Integer, String> map2 = new LinkedHashMap<Integer, String>();
        map2.putAll(map1);

        for (int i = 0; i < 10; i++) {
            long dbTimes = timeComparison(list1, list1)
                    + timeComparison(set1, set1)
                    + timeComparison(map1.keySet(), map1.keySet())
                    + timeComparison(map1.values(), map1.values());
            long times = timeComparison(list2, list2)
                    + timeComparison(set2, set2)
                    + timeComparison(map2.keySet(), map2.keySet())
                    + timeComparison(map2.values(), map2.values());
            if (i > 0)
                System.out.printf("double braced collections took %,d ns and plain collections took %,d ns%n", dbTimes, times);
        }
    }

    public static long timeComparison(Collection a, Collection b) {
        long start = System.nanoTime();
        int runs = 10000000;
        for (int i = 0; i < runs; i++)
            compareCollections(a, b);
        long rate = (System.nanoTime() - start) / runs;
        return rate;
    }

    public static void compareCollections(Collection a, Collection b) {
        if (!a.equals(b) && a.hashCode() != b.hashCode() && !a.toString().equals(b.toString()))
            throw new AssertionError();
    }
}

печатает

double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 34 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns

Для создания наборов вы можете использовать метод varargs factory вместо инициализации с двойной привязкой:

public static Set<T> setOf(T ... elements) {
    return new HashSet<T>(Arrays.asList(elements));
}

В библиотеке коллекций Google есть много удобных методов, таких как это, а также множество других полезных функций.

Что касается икры безсловности, я встречаюсь с ней и постоянно использую ее в производственном коде. Меня больше беспокоят программисты, которые путаются, когда идиома разрешается писать производственный код.

Эффективность в стороне, я редко нахожусь в желании создать декларативное собрание вне модульных тестов. Я считаю, что синтаксис двойной привязки очень читабельны.

Другим способом достижения декларативной конструкции списков является использование Arrays.asList(T ...) следующим образом:

List<String> aList = Arrays.asList("vanilla", "strawberry", "chocolate");

Ограничение этого подхода - это, конечно, что вы не можете управлять конкретным типом списка, который должен быть сгенерирован.

Там вообще ничего особенно неэффективно. Для JVM обычно не имеет значения, что вы создали подкласс и добавили к нему конструктор - что обычное повседневное дело на объектно-ориентированном языке. Я могу придумать довольно надуманные случаи, когда вы можете вызвать неэффективность, делая это (например, у вас есть многократно называемый метод, который заканчивается тем, что он смешивает разные классы из-за этого подкласса, тогда как обычный класс, который прошел, будет полностью предсказуемым, - в последнем случае компилятор JIT мог бы сделать оптимизацию, которая невозможна в первом). Но на самом деле, я думаю, что случаи, когда это имеет значение, очень надуманны.

Я вижу проблему более с точки зрения того, хотите ли вы "загромождать вещи" множеством анонимных классов. В качестве приблизительного руководства рассмотрите возможность использования идиомы не более, чем использовать, скажем, анонимные классы для обработчиков событий.

В (2) вы находитесь внутри конструктора объекта, поэтому "this" ссылается на объект, который вы создаете. Это не отличается от любого другого конструктора.

Что касается (3), это действительно зависит от того, кто поддерживает ваш код, я думаю. Если вы не знаете этого заранее, то тест, который я бы предложил использовать, - "видите ли вы это в исходном коде JDK?" (в этом случае я не помню, чтобы видел много анонимных инициализаторов, и, конечно же, не в тех случаях, когда это единственный контент анонимного класса). В большинстве проектов с умеренным размером, я бы сказал, что вам действительно понадобятся ваши программисты, чтобы понять источник JDK в какой-то момент, поэтому любой синтаксис или идиома, используемые там, являются "честной игрой". Помимо этого, я бы сказал, тренируйте людей по этому синтаксису, если у вас есть контроль над тем, кто поддерживает код, иначе комментировать или избегать.

Я изучал это и решил сделать более глубокий тест, чем тот, который был предоставлен действительным ответом.

Вот код: https://gist.github.com/4368924

и это мой вывод

Я с удивлением обнаружил, что в большинстве тестовых тестов внутреннее инициирование было фактически быстрее (в некоторых случаях почти вдвое). При работе с большими числами преимущество, похоже, исчезает.

Интересно, что случай, который создает 3 объекта в цикле, теряет выгоду, раньше, чем в других случаях. Я не уверен, почему это происходит, и нужно провести больше испытаний, чтобы сделать какие-либо выводы. Создание конкретных реализаций может помочь избежать переопределения определения класса (если это происходит)

Однако ясно, что в большинстве случаев не так много накладных расходов для отдельного объекта, даже с большими числами.

Один из вариантов назад - это тот факт, что каждое из инициалов двойной привязки создает новый файл класса, который добавляет весь блок диска к размеру нашего приложения (или около 1 к при сжатии). Небольшая площадь, но если она используется во многих местах, она может потенциально повлиять. Используйте это 1000 раз, и вы потенциально добавляете к вам приложение MiB, которое может быть связано со встроенной средой.

Мой вывод? Его можно использовать, если он не подвергается насилию.

Дайте мне знать, что вы думаете:)

Инициализация с двойной привязкой - ненужный хак, который может привести к утечкам памяти и другим проблемам.

Нет никакой законной причины использовать этот "трюк". Guava предоставляет отличные неизменные коллекции, которые включают как статические фабрики, так и строители, позволяя вам заполнять свою коллекцию там, где она объявлена ​​в чистом, понятном и безопасном синтаксис.

Пример в вопросе будет:

Set<String> flavors = ImmutableSet.of(
    "vanilla", "strawberry", "chocolate", "butter pecan");

Мало того, что это более короткое и легкое для чтения, но оно позволяет избежать многочисленных проблем с двойным шаблоном, описанным в других ответах. Конечно, он работает аналогично прямому построению HashMap, но он опасен и подвержен ошибкам, и есть лучшие варианты.

В любое время, когда вы считаете, что вам нужна двойная привязка, вы должны пересмотреть свои API или ввести новые, чтобы правильно решить проблему, вместо того, чтобы использовать синтаксические фокусы.

Error-Prone теперь обозначает этот анти-шаблон.

Хотя этот синтаксис может быть удобным, он также добавляет много этих ссылок на $0, поскольку они становятся вложенными, и может быть сложно отладить отладку в инициализаторы, если на каждой из них не установлены контрольные точки. По этой причине я рекомендую использовать это только для банальных сеттеров, особенно для констант и мест, где анонимные подклассы не имеют значения (например, без использования сериализации).

Марио Глейхман описывает, как использовать общие функции Java 1.5 для имитации Scala Список литералов, хотя, к сожалению, вы заканчиваете неизменяемыми списками.

Он определяет этот класс:

package literal;

public class collection {
    public static <T> List<T> List(T...elems){
        return Arrays.asList( elems );
    }
}

и использует его таким образом:

import static literal.collection.List;
import static system.io.*;

public class CollectionDemo {
    public void demoList(){
        List<String> slist = List( "a", "b", "c" );
        List<Integer> iList = List( 1, 2, 3 );
        for( String elem : List( "a", "java", "list" ) )
            System.out.println( elem );
    }
}

Коллекции Google, теперь входящие в Guava, поддерживают аналогичную идею для построения списка. В это интервью, Джаред Леви говорит:

[...] наиболее интенсивно используемые функции, которые появляются почти во всех классах Java, которые я пишу, являются статическими методами, которые уменьшают количество повторяющихся нажатий клавиш в вашем Java-коде. Это настолько удобно, что вы можете вводить команды, как показано ниже:

Map<OneClassWithALongName, AnotherClassWithALongName> = Maps.newHashMap();

List<String> animals = Lists.immutableList("cat", "dog", "horse");

7/10/2014: Если бы это было так просто, как Python's:

animals = ['cat', 'dog', 'horse']

Второй ответ Nat, за исключением того, что я использовал бы цикл вместо создания и немедленного броска неявного списка из asList (элементов):

static public Set<T> setOf(T ... elements) {
    Set set=new HashSet<T>(elements.size());
    for(T elm: elements) { set.add(elm); }
    return set;
    }

1. Это вызовет add() для каждого члена. Если вы можете найти более эффективный способ поместить элементы в хеш-набор, используйте его. Обратите внимание, что внутренний класс, скорее всего, сгенерирует мусор, если вы чувствительны к этому.

2. Мне кажется, что контекст - это объект, возвращаемый new, который является HashSet.

3. Если вам нужно спросить... Скорее: будут ли люди, которые придут после того, как вы это знаете или нет? Легко ли это понять и объяснить? Если вы можете ответить "да" на оба, не стесняйтесь использовать его.