Почему устаревшие методы не реконструируются?

Question

Из определения осуждается:

Элемент программы аннотированный @Deprecated является один, что программисты не рекомендуется использовать, как правило, потому что это опасно, или потому, что лучшая альтернатива существует.

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

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

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

Есть ли причины, почему это не сделано, и почему новые методы производятся с различными сигнатурами методов или в другом классе?

Answer 1

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

Рассмотрим класс

public class Math { 
    public static int add(int a, int b) { return a + b; } 
    public static int randomNumber() { return 12; } 
} 

Теперь кто-то понимает, что реализация randomNumber неисправна, потому что на самом деле возвращает постоянное значение. Кроме того, было бы неплохо включить upperBound. И это не имеет ничего общего с Math и, вероятно, следует перенести в класс Random вместо:

public class Math { 
    public static int add(int a, int b) { return a + b; } 

    @Deprecated 
    public static int randomNumber() { return 12; } 
} 

public class Random { 
    public static int randomNumber(int upperBound) { return /* some complex implementation */; } 
} 

То, что вы всегда должны делать, когда маркировка на вопрос, как @Deprecated это включить альтернативный метод следует использовать вместо этого.

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

Конечная нота: Что касается вашего заявления

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

Это очень плохая привычка с самого начала. В определении сделанного, где я работаю, написано, что код должен быть предупрежден бесплатным для выхода. Нам просто не разрешено использовать устаревшие методы. Если вы просто проигнорируете предупреждения и устаревшее сообщение, нет ничего, что мог бы сделать автор фреймворка. Разработчик, который не хочет адаптироваться, может продолжать работу, получить исходный код устаревшего метода и скопировать его туда, где он ему нужен.@Deprecated - это функция для разработчиков, которые знают об изменениях структуры и готовы и способны справиться с ними. Остальное просто не имеет значения. @Deprecated будет удален в какой-то момент, нарушив код тех, кто не хотел меняться.

Дополнение о примере: Давайте предположим, что мы имеем randomNumberBetween0And1, который неправильно реализован и всегда возвращает значения между 1 и 2. Пользователи этой функции есть в курсе, что ошибка изменилась их использование метода быть randomNumberBetween0And1() - 1 к компенсировать ошибку. Если вы теперь идите вперед и измените реализацию на правильную, фактически вернув что-то между 0 и 1, которое нарушит код всех, кто ранее компенсировал вашу ошибку с помощью вычитания 1 - эти люди теперь получат значение от -1 до 0 вернулся. То есть не что бы вы хотели.

Answer 2

Устаревшие методы не следует удалять.

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

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

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

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

Любые причины, почему это не сделано, и почему новые методы сделаны с различных определений методов или в другом классе вообще?

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

Answer 3

Некоторых причин для хранения устаревшего имени методы:

• коррекции орфографии/применить именования (но фиксируя метод сломает существующий код)

• фиксированный метод существует, но требует больше параметров для корректной работы , Таким образом, вызов одного параметра хранится с помощью второго параметра. (java.net.URLDecoder.decode())

• не простое исправление не существует, но удаление сломается код

Answer 4

Метод может быть DEPRECATED по различным причинам, которые делают ваше предложение невозможно. В большинстве случаев это не потому, что метод опасен. Это потому, что есть лучшая альтернатива.Например:

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

Даже если метод является опасным (например, Thread.stop()), некоторые люди могут знать, что метод опасен, осознают этот факт, но их код работает нормально и не работает затронутая этой проблемой, и переписывание ее будет стоить слишком дорого, если не будет ощутимой выгоды. Переписывание того же метода stop() без проблемы с исходным просто невозможно, потому что проблема присуща тому, что делает этот метод: остановка потока без его совместной работы.