Является ли хорошей практикой удаление функции вместо того, чтобы оставить ее с устаревшей аннотацией

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

мой встречный вопрос

Что, если бы разработчики Java просто удалили класс Date вместо того, чтобы объявить его устаревшим, и все равно не согласились бы.

Ожидание

Даже если я ошибаюсь, я ожидаю хорошего объяснения этому факту. Некоторые дополнительные факты или ссылки были бы замечательными.


java deprecated jls
person cafebabe1991    schedule 07.10.2014    source источник
comment
stackoverflow - это не то место, куда вы можете пойти, чтобы уладить споры   -  person Rocky Pulley    schedule 07.10.2014
comment
Это зависит от обстоятельств. В новой разработке вы должны удалить нефункциональный код как можно скорее, хотя и координируя свои действия с вашими коллегами. Однако, когда у вас есть общедоступный API, которым пользуются тысячи или миллионы, вы должны быть немного более осторожными.   -  person Hot Licks    schedule 07.10.2014
comment
И нет никаких фактов, подтверждающих это, так или иначе. Это решение основано на опыте, политике вашей группы и здравом смысле.   -  person Hot Licks    schedule 07.10.2014
comment
Если вы просто откажетесь от метода, люди просто продолжат его использовать. В любом случае, они игнорируют предупреждения — по крайней мере, это мой опыт. Удалите метод —> заставьте всех адаптироваться —> завтра у вас будет лучший код. Конечно, мы говорим об собственном коде с обеих сторон. Публичные библиотеки — совсем другое дело.   -  person Marko Topolnik    schedule 07.10.2014

Ответы (2)


arrow_upward
2
arrow_downward

Это может быть что-то для программистов.

Если вы создавали библиотеку, которую используют другие, новая версия не должна нарушать существующий код. Только после серьезной ревизии, скажем, с 3.8.7 до 4.0, вы можете потребовать от пользователей перекодировать код. Имейте в виду, что исправление других ошибок может привести к ответвлению, обратному переносу на новую версию 3.8.8.

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

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

Есть еще несколько вариантов использования @Deprecated локально:

У меня когда-то был метод с параметром long, который в новой версии будет Object. Я сделал это в библиотеке:

/**
 * Please replace the long parameter with the Object ...
 */
@Deprecated
public boolean f(long x) { ... }

public boolean f(Object x) { ... }

Здесь простое удаление старой версии было бы фатальным для всех применений библиотеки, за исключением уродливого if (x instanceof Long) { return fOld(((Long)x).longValue()); } в новой функции.

Таким образом, устаревание может дать информацию javadoc о том, чем заменить вызов. Обычно отображается в IDE как всплывающее окно.

person Joop Eggen    schedule 07.10.2014

arrow_upward
1
arrow_downward

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

Пункт

Однако в версии java "X" эта функция "abc" устарела по причине "xyz", но вы можете столкнуться с каким-то старым кодом в своей карьере, поэтому полезно знать об этом

Но это очень редкий случай, когда людям с Java придется что-то удалить, пометив что-либо как устаревшее. Флаг устаревшего просто говорит, что его не следует использовать в будущем. И это тоже справедливо, если учитывать вопросы, связанные с обратной совместимостью.

В связи с написанием API самостоятельно у вас могут быть свои обстоятельства.

person nobalG    schedule 07.10.2014