Как узнать, изменит ли определенный метод состояние java-объекта?

Некоторые методы являются методами-мутаторами, обычно они ничего не возвращают, так называемые сеттеры. Другие, такие как метод .plusDays() класса LocalDate, возвращают полный экземпляр объекта типа Localdate, поэтому, если вы хотите изменить объект, вам нужно указать существующую объектную переменную на вновь созданную.

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


java methods mutators
person victor cortez    schedule 21.09.2017    source источник
comment
Вы не можете сказать, изменяет ли метод состояние объекта (или любого другого), за исключением того, что вы просматриваете исходный код. LocalDate::plusDays также может изменить объект в сочетании с созданием и возвратом нового экземпляра.   -  person Flown    schedule 21.09.2017
comment
В javadoc должно быть указано это, как в упомянутом вами методе: возвращает копию этого LocalDate...   -  person Arnaud    schedule 21.09.2017
comment
если у класса Foo есть метод, который возвращает Foo, то он является кандидатом на неизменяемый класс... документ тоже может быть полезен   -  person ΦXocę 웃 Пepeúpa ツ    schedule 21.09.2017
comment
Чтобы знать наверняка (-иш), вам нужно посмотреть документацию, но вы можете догадаться по названию (set*, add*, глаголы будут видоизменяться, а союзы и существительные - нет).   -  person Ry-♦    schedule 21.09.2017
comment
Что ты имеешь в виду под заранее? Прежде чем вы решите использовать его в своем коде? Или перед вызовом во время выполнения (например, через отражение)?   -  person dimo414    schedule 21.09.2017
comment
Как я могу сделать все возможное, чтобы не читать документацию, как разумный человек?   -  person Kayaman    schedule 21.09.2017
comment
@Kayaman Разработчиков никогда не следует заставлять читать документацию, если только они не создают реализацию. Вот почему такие языки, как Rust, пытаются реализовать это во время компиляции. Никому не нравится, когда его заставляют читать документы для ясности.   -  person Dioxin    schedule 21.09.2017
comment
@VinceEmigh У нас есть много разработчиков, которые еще не читают документацию. Я не думаю, что это то, к чему нужно стремиться, когда нужно что-то сделать, вместо того, чтобы придерживаться каких-то героически звучащих идеалов, основанных на мнении какого-то психа.   -  person Kayaman    schedule 21.09.2017
comment
@ dimo414 dimo414 извините, в конкретном контексте этого вопроса заранее означает решить использовать его в моем коде.   -  person victor cortez    schedule 21.09.2017
comment
@Kayaman спасибо за встряску реальности, документация действительно хороший ресурс, но вопросы направлены на то, чтобы выяснить, есть ли какие-либо индикаторы с точки зрения кода или, возможно, с точки зрения дизайна языка.   -  person victor cortez    schedule 21.09.2017
comment
@Kayaman Вы читали JLS от начала до конца? А JVMS? Вы их используете, так что вы должны были прочитать документацию, да? Или, может быть, вы похожи на большинство, которые ссылаются на него только тогда, когда происходит что-то странное и вам нужен официальный ответ. Подумайте о холодильнике или выключателе: вы им пользуетесь, но сколько вы в нем прочитали? Согласны ли вы с тем, что пользователи холодильника или выключателя света не должны быть обязаны читать документацию, чтобы чувствовать себя в безопасности при правильном использовании? Да, это было бы полезно, но быть вынужденным?   -  person Dioxin    schedule 21.09.2017
comment
@VinceEmigh Что ж, с современными IDE довольно сложно не читать javadocs. Если бы JLS всплыл таким образом, я бы тоже читал его намного больше. Я не очень понимаю, почему ваша ненависть к документации так сильна. Это потому, что его обычно не существует, или, в худшем случае, это неправильно? Итак, вы хотите найти человека, который написал код и документацию, и задушить их обоих? Если да, то я полностью понимаю.   -  person Kayaman    schedule 21.09.2017
comment
@Kayaman Это не ненависть к документации, вероятно, не продлилась бы так долго, если бы я ее презирал. Это мышление, что мы должны зависеть от документации. Надежный интерфейс может избавить от необходимости читать документацию. Документация неизбежна во многих ситуациях, но мы должны отходить от нее (как обычные объекты реального мира), а не навязывать ее. Считайте это философией чокнутого, но разве вы не рады, что нас не заставляют читать JLS и JVMS, чтобы писать программы на Java? Документы для новых, потенциально малоизвестных функций имеют смысл. Изменчивость не одна, ИМО. Просто мнение   -  person Dioxin    schedule 21.09.2017

Ответы (2)


arrow_upward
5
arrow_downward

Нет, нет никакого способа узнать (за исключением просмотра документации или реализации), изменит ли метод какое-либо состояние.

Методы, возвращающие void, обычно изменяют какое-то состояние (иначе что они делают?), но нет гарантии, что что изменится (варианты включают объект, одно из его полей, метод параметры, глобальное состояние или даже сама среда выполнения JVM).

Не существует универсального способа определить, будут ли методы, возвращающие что-то, также иметь другие побочные эффекты< /а> или нет.

Если тип неизменяемый, вы можете быть уверены, что ни один из его методов не изменит свое собственное состояние, но тогда вопрос просто сместился на «как узнать, является ли тип неизменным или нет?» На этот вопрос ответить проще, но все же сложно. Инструменты статического анализа, такие как ErrorProne @Immutable полезна, но все же допускает ошибки.

person dimo414    schedule 21.09.2017

arrow_upward
1
arrow_downward

Что ж, чистые сеттеры, которые следуют шаблону void setProperty(PropertyType property), скорее всего, изменят внутреннее состояние (хорошо, можно было бы реализовать это по-другому, например, изменить состояние переданного параметра, но это было бы странно).

Например, методы, найденные в Builders (например, Builder withProperty(PropertyType property)), могут свободно выбирать, будут ли они обновлять состояние фактического экземпляра или создавать и возвращать новый экземпляр, содержащий обновленное свойство.

В конце концов, нельзя предвидеть, была ли выбрана та или иная стратегия реализации, просто взглянув на метод, поэтому нужно читать документы (а иногда и код).

person Florian Fray    schedule 21.09.2017