Что сделает обратную совместимость невозможной?

Question

У нас есть компонент платформы (написанный на Java), который теперь должен быть обратно совместимым в течение определенного периода, например, 3 года.Возможно ли, что для реализации новой функции или исправления ошибки потребуется изменение интерфейса в платформе?

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

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

Answer 1

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

Да, если эта ошибка является случайным нарушением обратной совместимости и если вы выпустили несколько версий (X + 1 ... X + N) продукта до его обнаружения. Итак, одна часть ваших клиентов зависит от более старой версии X, а другая часть клиентов зависит от сломанных версий X + 1 ... X + N. И если вы исправите эту ошибку, новые клиенты (X + 1 ... X + N) будут сломаны.

Является ли хорошей идеей создать новый интерфейс, расширяющий оригинальный интерфейс новым методом?

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

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

Существует 3 вида обратной совместимости: двоичная (работающие старые клиенты), исходная (перекомпиляция старых клиентов) и поведенческая . Если вам нужно добавить новый метод в интерфейс, то вы можете только нарушить совместимость с исходным кодом, но сохранить двоичную совместимость, проверив используемую версию интерфейса (final String VERSION = "N") и вызывая новый метод только для совместимых версий. Итак, если какой-то старый клиент нуждается в новой функции, ее следует изменить и перекомпилировать.