Краткий ответ: в Java нет ничего более близкого, чем хотелось бы, но есть альтернативы. Шаблон делегата не сложно реализовать, просто он не так удобен, как с Objective-C.
Причина, по которой «неофициальные протоколы» работают в Objective-C, заключается в том, что язык поддерживает категории , которые позволяют добавлять методы к существующим классам, не помещая их в подклассы или даже не имея доступа к исходному коду. Таким образом, большинство неформальных протоколов являются категорией на NSObject. Это явно невозможно в Java.
Objective-C 2.0 выбирает методы @optional протокол, который является намного более чистой абстракцией и предпочтителен для нового кода, но еще дальше от аналога в Java.
Честно говоря, самый гибкий подход - определить протокол делегата, а затем классы реализуют все методы. (В современных IDE, таких как Eclipse, это тривиально.) Многие интерфейсы Java имеют сопутствующий класс адаптера, и это общий подход, при котором пользователю не требуется реализовывать много пустых методов, но он ограничивает наследование, что делает дизайн кода негибким , (Джош Блох рассматривает это в своей книге «Эффективная Java».) Я бы предложил сначала предоставить только интерфейс, а затем добавить адаптер, если это действительно необходимо.
Что бы вы ни делали, избегайте бросания UnsupportedOperationException
для "невыполненных" методов. Это заставляет делегирующий класс обрабатывать исключения для методов, которые должны быть необязательными. Правильный подход заключается в реализации метода, который ничего не делает, возвращает значение по умолчанию и т. Д. Эти значения должны быть хорошо документированы для методов, которые не имеют возвращаемого типа void.