Предлагаемый вариант решения
Интерфейс не делится на два; вместо этого все неизменяемые методы обозначаются ключевым словом const, это свойство наследуется. Все константные ссылки обозначаются ключевым словом const, что позволяет находить ошибки на стадии компиляции. Критерий тот же, что и в С++: запрещается вызывать неконстантные методы объекта в теле константного метода, ссылки на сам объект и все его поля в контексте этого метода константны. Вызывать неконстантные методы через константную ссылку, а также присваивать константную ссылку неконстантной запрещается.
В случае необходимости, используя ключевое слово mutable, разрешается вызывать неконстантные методы этого же объекта в константном методе, в константном методе присваивать неконстантной ссылке значение this или значения полей этого же объекта. Наличие ключевого слова mutable служит сигналом компилятору для вставки проверки того, что состояние объекта не изменилось; эта проверка аналогична постусловию в Eiffel-варианте и выполняется по завершении работы метода независимо от того, сколько точек возврата имеет метод (это может быть реализовано либо с помощью прокси-метода, либо вставкой проверки во все точки возврата). Для осуществления проверки перед выполнением метода копируется исходное состояние объекта. Также проверка выполняется при выходе из метода в случае исключительной ситуации. Проверка осуществляется во время выполнения только в отладочной версии независимо от того, выполнялась или нет часть метода, которая содержит инструкцию mutable. В случае если проверка не прошла генерируется исключение. На число использований ключевого слова mutable в теле метода ограничений не накладывается. Должен быть определен метод, который задает критерий оценки неизменности состояния, этот метод будет вызываться в проверке вставляемой компилятором. Использование ключевого слова mutable в таком методе запрещено.
Отличие от варианта С++ состоит в том, что const означает не физическую, а наблюдаемую неизменность объекта. Разница с Eiffel в том, что в случае, когда метод физически константен, проверка не вставляется, а также в том, что механизм обеспечения неизменности является дополнением к уже существующим элементам языка.
Описанный механизм может быть реализован либо в рамках существующих языков программирования с проведением необходимого анализа на возможность интеграции с существующим окружением, либо в новых языках. Вот как это может выглядеть в контексте С++ (в качестве примера выбран operator==(), который задает условие логической константности):
В классе Personal переопределен оператор сравнения, который задает условие логической неизменности. В операторе проверяется, что логическое содержание объектов эквивалентно (несмотря на то, что на момент проверки данные могут быть не загружены в память). Также отметим, что переопределение операторов копирования и сравнения не является специальной реализацией этих методов для поддержки предлагаемого механизма. Такая их реализация продиктована семантикой интерфейса Personal; мало проку при сравнении двух персон сравнивать значения указателей вместо содержимого изображений. Если необходим метод, осуществляющий сравнение физического содержания всех полей, его можно реализовать дополнительно. В данном случае объект имеет пять константных методов; четыре из них (ReadPictureFromFile, Name, Age, operator==) будут проверены на стадии компиляции, а пятый, метод Picture, - во время выполнения в соответствии с заданным в operator== условием неизменности (при его реализации была использована инструкция mutable).
Плюсы предложенного подхода: используется специальный механизм, что позволяет компилятору контролировать неизменность; в большинстве случаев это будут ошибки компиляции, в ряде случаев ошибки времени выполнения; не нужно делить интерфейс на два - меньше работы программисту; количество проверок времени выполнения по сравнению с вариантом Eiffel невелико и равно количеству случаев, когда физическая неизменность не совпадает с логической, вследствие чего нет потерь в скорости работы; механизм не конфликтует с рядом специфичных для объектно-ориентированного подхода принципов, например, с ковариантным переопределением параметров.
Минусы: в отладочной версии, когда физическая неизменность не совпадает с логической и для хранения информации о состоянии проверяемого объекта требуется большой объем памяти, возможно значительное потребление ресурсов, что может сказаться на скорости работы программы.
Проблеме неизменности посвящено множество публикаций [5-9]. Представленный вариант снимает имеющиеся трудности и может быть использован для решения проблемы обеспечения свойства неизменности для объектов.
