Для программирования на Java, каковы преимущества использования метода @Deprecated для нотации и интерфейса, но не для класса, который его реализует?Каковы преимущества использования нотной нотации @Deprecated на интерфейсе?
public interface Joe {
@Deprecated
public void doSomething();
...
}
public final class Joseph implements Joe {
public void doSomething() {
...
}
...
}
Я считаю, что это недостаток самого языка Java, и бессмысленно указывать метод в интерфейсе как устаревший с помощью аннотации и не иметь метода, который считается устаревшим в классе реализации.
Было бы лучше, если бы @ устаревший метод был унаследован. К сожалению, похоже, что Java не поддерживает это.
Рассмотрите, как инструмент, такой как IDE, рассматривает эту ситуацию: если тип переменной объявлен как интерфейс, то методы @deprecated могут быть визуализированы с ударом. Но если тип переменной объявляется классом реализации, а подпись класса не включает @deprecated, то метод будет отображаться без пробития.
Основной вопрос: что это значит для метода, который должен быть устаревшим в интерфейсе, но не в классе реализации (или в расширяемом интерфейсе)? Единственное разумное намерение состоит в том, чтобы этот метод был устаревшим для всего, что находится под интерфейсом в иерархии классов. Но язык не поддерживает это поведение.
на мой взгляд, это спорным: устаревший интерфейс метод не должен не использоваться независимо от его реализации (просьба контрпримеры, если нет)
я бы пойти дальше, чем спорное: Я бы сказал, что это сомнительно. Я бы попросил, чтобы это было оправдано в обзоре кода. – CPerkins
Почему бы и нет? Это просто означает, что один метод в интерфейсе с несколькими методами планируется удалить в будущих выпусках. –
@Eugene: Это может быть правдой, но в примере показан только один метод. Итак, почему даже этот интерфейс есть, если у него есть только один метод?:/lol – Zack
@Deprecated документация. Если люди обращаются к интерфейсу, вы можете отметить некоторые аспекты этого интерфейса как устаревшие. Таким образом, люди знают, что не использовать его.
Класс реализации интерфейса - это деталь. Метод в этом классе удовлетворяет интерфейсу, но сам по себе он не может быть устаревшим. Устаревший способ может быть или не быть уместным.
Создание нового класса, реализующего интерфейс, означает, что вам необходимо реализовать устаревшие методы. Они, вероятно, должны работать, если вы не знаете, что клиенты класса не используют устаревшие методы. Например, если вы создаете контейнер сервлетов HTTP, вам необходимо реализовать метод HttpServletResponse.encodeUrl(), хотя он устарел в пользу encodeURL(). Это связано с тем, что пользователь вашего класса может вызывать этот устаревший метод.
Расширение на «Устаревшее, что метод [реализации] может быть или не подходит». В частности, может быть, что метод интерфейса doSomething не подходит для всех реализаций Joe, но подходит для этой конкретной реализации Joseph - таким образом, устаревание в интерфейсе, но не в этой конкретной реализации. – drew
Если мы хотим реорганизовать существующий код с помощью несоответствующих методов в интерфейсе и в реализации, то мы можем использовать @Deprecated в методах интерфейса в пользу чистых новых методов временно для нескольких выпусков. Это может быть уродливым, просто чтобы поддерживать обратную совместимость кода, мы можем использовать его. Это будет показано в отчете IDE и SONAR, что его устаревший метод и принуждение клиентов использовать новые методы.
Почему бы вам вообще не обесценить метод -only в интерфейсе? Просто добавьте в свои выпуски документы, что «Интерфейс« Joe »не используется, рекомендованный для использования». или что-то. – Zack
Существуют другие методы для интерфейса и класса. Извините Зак за путаницу. –