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

Question

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

Можно ли написать наш код таким образом, чтобы это предотвратить?

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

У вас есть идеи?

Answer 1

По сути, вы включаете какой-то механизм версий (как правило, с большей степенью детализации, чем просто ограничения для низких / высоких версий), и вы пытаетесь сохранить интерфейсы отдельными и "ортогональными".Но многое зависит от того, на какой стороне интерфейса вы находитесь.Со стороны «потребителя» вы можете сделать только очень многое.

IBM System / 38 и его потомкам удалось сохранить совместимость таким образом, чтобы программы, скомпилированные в первом выпуске, можно было запускать без перекомпиляции 30 лет спустя (и через две ревизии из набора машинных инструкций вторая довольно радикальная).Но это необычный случай довольно хорошего (хотя и не идеального) оригинального дизайна в сочетании с довольно сильной мотивацией (крупные банки, которые тратят много денег на системы) для поддержания совместимости.

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

Answer 2

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

Замечания к выпуску для Mac OS X

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