Что касается Java, как бы вы вели себя с таким свойством? Уже есть способы сделать объекты неизменяемыми, что, возможно, является лучшим способом достижения этого с дополнительными преимуществами. Фактически вы можете эмулировать поведение const, объявив суперкласс / суперинтерфейс, который реализует только методы, которые не меняют состояние, и затем имея подкласс / субинтерфейс, который реализует методы мутирования. Передача вашего изменяемого класса в экземпляр класса без методов записи, другие биты кода не могут изменить объект, не передав его обратно в изменяемую версию (что эквивалентно отбрасыванию const).
Даже если вы не хотите, чтобы объект был строго неизменным, если бы вы действительно хотели (что я бы не рекомендовал), вы можете установить для него какой-то режим «блокировки», чтобы его можно было изменять только при разблокировке. , Пусть методы блокировки / разблокировки будут частными или защищены в зависимости от ситуации, и вы получите некоторый уровень контроля доступа. В качестве альтернативы, если вы не собираетесь, чтобы метод вообще принимал его в качестве параметра, чтобы изменить его, передать копию этого объекта или если копирование всего объекта слишком тяжелое, тогда какой-то другой легкий объект данных, содержащий только необходимые Информация. Вы даже можете использовать динамические прокси для создания прокси для вашего объекта, который превращает любые вызовы методов мутации в no-ops.
По сути, уже есть целый ряд способов предотвратить мутацию класса, который позволяет вам выбрать тот, который наиболее подходит для вашей ситуации (подсказка: выбирайте чистую неизменность везде, где это возможно, так как это делает объект тривиально поточнобезопасным и легче рассуждает) с в общем). Не существует очевидной семантики того, как можно реализовать const, что могло бы стать улучшением этих методов, было бы еще одним уроком, который либо не обладал бы гибкостью, либо был бы настолько гибким, что бесполезным.
То есть, если я не пропустил что-то, что вполне возможно. : -)