Почему Java не имеет делегатов метода?

[Мелкие правки]

Позвольте мне сначала сказать, что я не против или за добавление делегатов на Java. Я просто объясняю предысторию.

Во-первых, команда Sun's Java традиционно более консервативна (по сравнению с командой C#) в отношении эволюции языка.

Во-вторых, добавление конструкции делегата на Java, вероятно, потребует введения нового ключевого слова, например: "делегат". Это сломает существующий код, в котором есть переменные с именем "делегат".

В-третьих, существует принцип конструирования, называемый "Принцип единого выбора" http://en.wikipedia.org/wiki/Single_choice_principle. При применении к проектированию языка это означает, что у программиста должен быть только один очевидный способ чего-то добиться. Или, другими словами, множественный выбор - рискованно. Введение делегатов в Java будет работать против этого принципа, так как их поведение может быть достигнуто с помощью анонимных классов.

[Конечно, этот принцип не следует воспринимать буквально.] Если бы это было так, мы бы программировали на старой доброй машине Тьюринга. Наверное, ребята из "Солнца" посчитали, что делегаты не представляют собой выгоду, которая перевешивает нарушение единственного выбора]

[Конечно же, этот принцип не следует воспринимать буквально.

Простота.

Не вводя понятие делегатов на Java, они упростили язык. Подобно тому, как не имея свойств, индексаторы, ....

(использование более простого языка, кстати, не обязательно проще; возможно, им следовало бы добавить делегатов, но они не так принимали проектные решения)

java не имеет замыканий, так как он был задуман не как функциональный язык, а как объектно-ориентированный
. так как во многих случаях можно подделать другую языковую парадигму, в данном случае используя анонимные интерфейсы вместо замыкания
. но сейчас все меняется и под давлением новых языков jvm, таких как scala, groovy, jruby и т.д., которые сочетают oo и funcional парадигмы, java комитет пытается поставить замыкания в java 7.

В Java, вы имеете внутренние классы, которые привязаны к одному конкретному экземпляру родительского класса и имеют прямой доступ к его членам. Таким образом, реализация внутреннего класса не требует (гораздо) большего количества кода, чем написание метода.

C# не имеет внутренних классов. Как внутренние классы (как на Java), так и делегаты (как на C#) имеют свои преимущества (иногда я скучаю по внутренним классам на C#), но с точки зрения дизайнера языка имеет смысл придерживаться любого из них (а не поддерживать оба), так как это делает дизайн библиотеки классов более последовательным.

Может быть, потому что если метод должен передаваться и делиться между объектами, то он не должен принадлежать одному единственному классу. Вероятно, он должен быть передан через собственный класс. Я имею в виду, что переходная функция действительно чувствует себя немного странно, если подумать об этом. Наверное, это плохо.

Я РЕАЛЬНО люблю делегатов для работы с пользовательским интерфейсом. Это значительно облегчает программирование оконных действий.

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

Не уверен, что я предпочитаю.

Делегаты на C# выглядят уродливо. (объявив что-то переменной, а затем добавив () после того, как ему станет плохо в ООП)

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

Вы можете просто использовать java.lang.reflect.Method

Edit: Как Вы уже говорили, использование рефлексии - не очень хороший подход. Это правда, но использование делегатов, с точки зрения ООП, на мой взгляд, не является лучшим подходом. Это функционально-языковая конструкция

Потому что они думали, что:

связанные методы ссылки [делегаты] просто ненужны. [...] Более того, они отвлекают от простоты и единства языка Java. Связанные методы Ссылки не являются правильным путем для будущей эволюции языка.

Взятые из этой (старой) белой бумаги:

http://java.sun.com/docs/white/delegates.html

Теперь Java рассматривает возможность добавления их, как только язык будет развиваться достаточно. Я уверен, что они скоро будут на языке (по крайней мере, раньше, чем Perl 6: P)

Вы также можете использовать: Способ обратного вызова программного обеспечения

Для того, что он стоит, я внедрил поддержку обратного вызова / делегата в Java с использованием размышлений. Детали и рабочий источник доступны на моем сайте .