, то вы должны быть уверены, что любой потомок
C, который не переопределяет
f, получит новую версию
f, и что каждое обращение к
f клиента
C или потомка
C будет запускать эту новую версию.
Традиционные подходы к этой проблеме предполагают работу вручную, заставляя разработчиков записывать все зависимости и прослеживать их изменения, используя специальные механизмы, известные как "создавать файлы" и "включать файлы". Это неприемлемо в современных разработках программных продуктов, особенно в ОО-мире, где взаимозависимости между классами, вытекающие из отношений наследования, часто сложны, но могут быть выведены из систематического рассмотрения текста ПО.
Обновление системы после изменения должно быть автоматическим, а анализ межклассовых зависимостей выполняться инструментарием, а не вручную разработчиками.
Это требование можно удовлетворить в компилируемой среде (где компилятор будет работать вместе с инструментарием, выполняющим анализ зависимостей), в интерпретируемой среде или в среде, сочетающей обе эти техники реализации языка.
Быстрое обновление (fast update)
На практике механизм обновления системы должен быть не только автоматическим, но и быстрым. Более точно, он должен быть пропорциональным размеру изменений, а не размеру системы в целом. Без этого свойства метод и среда могут быть применимыми только к небольшим системам, а применять их нужно к большим.
Время обработки ряда изменений в системе, создающих обновленную версию, должно быть функцией размера измененных компонентов и не зависит от размера системы в целом.
И компилируемая, и интерпретируемая среда могут удовлетворять этому критерию, хотя в последнем случае компилятор должен быть инкрементным (он не должен все компилировать заново). Наряду с инкрементным компилятором, среда может, конечно, включать глобальный оптимизирующий компилятор, работающий на всей системе. При условии, что глобальный компилятор нужен только для выпуска конечного продукта, разработка будет в основном использовать инкрементный компилятор.
Многие приложения, вероятно, большинство, требуют сохранения объектов от одного сеанса до следующего. Среда должна обеспечивать механизм выполнения этого простым способом.
Объект часто содержит ссылки на другие объекты, тоже содержащие, в свою очередь, ссылки на объекты. Поэтому каждый объект может иметь большое количество зависимых объектов с возможно сложным графом зависимости (который может содержать циклы). Обычно не имеет смысла сохранять или восстанавливать объект без всех его прямых и непрямых зависимых объектов. Говорят, что механизм живучести поддерживает замыкание живучести (persistence closure), если он может автоматически сохранять зависимые объекты наряду с самим объектом.
