Почему метод (не) должен быть одновременно аксессором и мутатором?
Многие методы Java в JDK, такие как List.set() и Map.put(), изменяют объект и возвращают результат вместо разделения мутатора и метода доступа.
Мне кажется, что для большинства этих методов возвращаемое значение является скорее побочным эффектом, и было бы бессмысленно иметь отдельный метод для его получения.
Но есть ли у каждого подхода другие преимущества и недостатки? Как мне решить, какой способ более подходящий?
Например, я создаю объект-симулятор, вызывая метод runSimulation(), и мне нужен результат boolean. Я мог бы сохранить его в объекте симулятора и вернуть в отдельном методе доступа, вызываемом после, или вернуть его в самом мутаторе, как я это делаю сейчас.
@ThexPhi Если вы прочитаете вопрос, то поймете, что это концептуальный вопрос.
Нет абсолютно ничего плохого в методе, который выполняет некоторую работу (изменяет состояние класса), а также возвращает значение. Сохранение значения в поле класса и его возврат отдельным методом создает дополнительную работу как для класса, так и для его клиентов и не приносит никакой пользы.
Я изменил формулировку вопроса так, чтобы ответы, скорее всего, были в основном основаны на мнении. Если рецензент прочитает это, прокомментируйте, есть ли еще что-нибудь, что можно сделать, чтобы "снять задержку" с этим вопросом.
Prime624624, я только что узнал, что этот вопрос помещается в "очередь повторного просмотра" только в том случае, если он редактируется вами в течение 5 дней после постановки на удержание. Поэтому, пожалуйста, внесите какие-либо изменения в этот вопрос (возможно, перефразируйте какое-нибудь предложение), чтобы это вызвало.
@JensBannmann Спасибо за помощь. Я рад, что вокруг есть несколько хороших пользователей. Я сделал правку. Кажется довольно мелочным, что переформулировка вопроса может сделать его открытым. Содержание и идея одинаковы.
Ответы 1
Если runSimulation () не является блокирующим методом, и вы хотите запускать его асинхронно, чтобы он не блокировал ваш основной поток, нет никакого вреда в возврате результата тем же методом, с помощью которого вы создаете симуляцию, при условии, что его можно вернуть. дешево.
Иногда это вопрос удобства: является ли дизайн вашего объекта таким, что пользователи почти всегда будут запрашивать результат после создания / запуска моделирования? Тогда было бы неплохо вернуть результат в методе изменения (возможно, вы могли бы назвать метод «runSimulationForResult ()»).
Иногда это вопрос эффективности: для некоторых типов реализаций списков (LinkedList и т. д.) Вызов get (), за которым следует set (), означает, что список просматривается дважды, а не один раз, и даже если это не самый распространенный шаблон. , дизайнеры решили, что в возврате предыдущего значения нет никакого вреда, так как это можно сделать практически бесплатно, а некоторые идиомы будут обрабатываться вдвое быстрее.
Я никогда не думал о примере со списком таким образом, но это имеет смысл. В моем случае возвращение логического значения отдельным методом не будет стоить дополнительных затрат, но методы всегда будут вызываться вместе, поэтому я просто включу его в мутатор.
Приведите актуальный код, и мы разберемся, что вам нужно!