Когда я вижу такие фрагменты кода, как
interface A {
void a();
void b() default { System.out.println("b"); };
void c() final { System.out.println("c"); };
}
У меня есть один вопрос. Разве у нас уже недостаточно дерьма в Java? Зачем это может понадобиться?
Предлагаю вам посмотреть эту конференцию: http://medianetwork.oracle.com/media/show/16999
Это все объясняет. Самое интересное, что можно сделать, — позволить интерфейсу развиваться, не переписывая всю кодовую базу. Это ключ к тому, чтобы большая кодовая база развивалась и не становилась все более и более ущербной.
Нам это нужно, потому что это приведет ребят из Scala в ярость. У них уже есть довольно схожая функциональность в виде «черт», поэтому теперь им нужно заставить их работать вместе с ними.
Разозлить ребят из Scala — буквально высший приоритет в разработке языка Java.
Планируется, что Java 8 будет содержать некоторую форму поддержки лямбда-выражений и замыканий, что станет большим шагом в модернизации языка Java. Проблема в том, что существующие библиотеки, основанные на интерфейсах, такие как структура коллекций, не смогут напрямую использовать эти новые функции. Невозможно добавить метод в интерфейс, не нарушая существующие реализации, они просто больше не будут компилироваться.
Иметь лямбда-выражения, но не иметь возможности легко использовать их со стандартными коллекциями, было бы огромным разочарованием для разработчиков Java. Для интеграции лямбда-выражений в стандартные коллекции весьма желательны такие методы, как forEach, map или filter.
Решение этой проблемы заключается в добавлении еще одной функции, методов расширения, которые определяют реализацию метода по умолчанию в интерфейсе. Существующие подклассы будут использовать метод по умолчанию, но также можно переопределить метод с помощью специализированной и, возможно, лучшей реализации.
Дополнительную информацию о предложении метода расширения можно найти в Предложение по улучшению Java 126.
interface X, X2,.. больше нет! О времени.
- person Voo; 27.01.2012
Это здорово, потому что позволяет вам, разработчику API, расширять интерфейсы апостериорно, не вызывая NoSuchMethodErrors. Вы также предоставляете реализации по умолчанию для методов в версии 2 для классов, скомпилированных для версии 1; код работает как шарм. Это также позволяет вам переопределить реализацию по умолчанию в классах, скомпилированных для V2, как обычно, и делает нумерованные интерфейсы излишними. Я считаю, что это также лучше, чем методы расширения использования сайта.
Я считаю, что концепция «методов расширения» — это не более чем последний шанс взломать/исправить плохо спроектированные API, которые были открыты «внешнему миру». Просто синтаксический сахар.
AbstractCollection должен уйти, а ты используешь java.lang.reflect.Proxy, но кого это волнует.
- person Tom Hawtin - tackline; 27.01.2012
Collection или Statement вместе с другим классом?
- person Tom Hawtin - tackline; 27.01.2012
