Денис Загаевский, эти вопросы придумал я, алллооо
Если бы я точно, доскональна, детально знал и мог найти в интернете определение без противоречий, зачем спрашивал бы тогда... Ты мне скажи что такое.
конечно у immutable объекта поле должено быть immutable
потому что изменение объекта в поле = изменение поля, что и есть mutable (изменение) по определению,
крч изменение объекта = изменение (mutate)
НО! изменить состояние можно через что-то — методы или публичные поля, так что нужно на это скорее обращать внимание
оба примера в данном виде у вас immutable, тк непубличные свойства, нет мутаторов (сеттеров и прочих методов)
Максим Федоров, ну и приватных нет свойств. Можно запросто добавить в эти же файлы третий класс, который поменяет состояние-состояния в 1 примере (цифру 5), и состояние во 2 примере (ссылку). Значит оба mutate.
Максим Федоров, Вообще-то в кодах, которые я приложил и создания объекта Solution нет. А мы говорим про этот объект - какой он. Значит где-то он создаётся, в коком-то уже существующем, не указанном здесь классе. Так вот, в этом классе, можно после создания объекта, командой, менять... – по определению это mutate оба. А final убрать так нельзя.
В состояние объекта входит состояние объектов сложных типов. С формальной точки зрения объекты обоих ваших классов являются изменяемыми. Однако в JVM существует понятие effectively final - это мутабельный объект, состояние которого не изменяется, хоть и не форсируется модификаторами private и final. Если JVM поймёт, что конкретный объект вашего класса не меняется (другими словами, является effectively final), то к этому объекту могут применяться оптимизации, характерные для неизменяемых объектов.