«Идеальное число аргументов для функции - ноль» - совершенно неверно. Идеальное количество аргументов - это именно то количество, которое необходимо, чтобы ваша функция не имела побочных эффектов. Меньше этого, и вы без необходимости заставляете свои функции быть нечистыми, вынуждая вас уклоняться от пропасти успеха и подниматься на градиент боли. Иногда «дядя Боб» замечателен своим советом. Иногда он совершенно неправ. Его нулевой аргумент совет является примером последнего
( Источник: комментарий @David Arno под другим вопросом на этом сайте )
Комментарий набрал впечатляющее количество голосов - 133, поэтому я хотел бы обратить более пристальное внимание на его достоинства.
Насколько я знаю, в программировании есть два разных способа: чисто функциональное программирование (что обнадеживает этот комментарий) и говорить, не спрашивать (что время от времени рекомендуется и на этом сайте). AFAIK, эти два принципа в корне несовместимы, близки к тому, чтобы быть противоположностями друг другу: чистый функционал может быть обобщен как «только возвращаемые значения, не имеют побочных эффектов», в то время как скажите, не спрашивайте, можно суммировать как «ничего не возвращать, есть только побочные эффекты ". Кроме того, я немного озадачен, потому что я думал, что слово «не спрашивать» считалось ядром парадигмы ОО, тогда как чистые функции считались ядром функциональной парадигмы - теперь я вижу чистые функции, рекомендуемые в ОО!
Я полагаю, разработчики должны выбрать одну из этих парадигм и придерживаться ее? Ну, я должен признать, что никогда не мог заставить себя следовать. Часто мне кажется удобным вернуть значение, и я не могу понять, как мне добиться того, чего я хочу достичь, только с побочными эффектами. Часто мне кажется удобным иметь побочные эффекты, и я не могу понять, как мне добиться того, чего я хочу достичь, только возвращая значения. Кроме того, часто (я думаю, это ужасно) у меня есть методы, которые делают оба.
Тем не менее, из этих 133 возражений я рассуждаю о том, что в настоящее время чисто функциональное программирование "выигрывает", поскольку становится консенсусом, который лучше сказать, не спрашивайте. Это верно?
Поэтому на примере этой игры с антипаттернами я пытаюсь сделать так : если бы я хотел привести ее в соответствие с чисто функциональной парадигмой - КАК ?!
Мне кажется разумным иметь состояние битвы. Поскольку это пошаговая игра, я сохраняю боевые состояния в словаре (многопользовательский - многие игроки могут играть одновременно много сражений). Всякий раз, когда игрок делает свой ход, я вызываю соответствующий метод в состоянии битвы, который (а) соответствующим образом изменяет состояние и (б) возвращает обновления игрокам, которые сериализуются в JSON, и в основном просто рассказывают им, что только что произошло на доска. Это, я полагаю, является вопиющим нарушением ОБА принципов и в то же время.
ОК - я мог бы сделать метод ВОЗВРАТИТЬ состояние битвы вместо того, чтобы изменить его на месте, если бы я действительно хотел. Но! Придется ли мне тогда копировать все в состоянии битвы без необходимости, просто чтобы вернуть полностью новое состояние вместо того, чтобы изменить его на месте?
Теперь, возможно, если этот шаг является атакой, я мог бы просто вернуть персонажей, обновленных HP? Проблема в том, что все не так просто: правила игры, ход может и часто будет иметь гораздо больше эффектов, чем просто удаление части HP игрока. Например, это может увеличить расстояние между персонажами, применить спецэффекты и т. Д. И т. Д.
Мне кажется намного проще просто изменить состояние и вернуть обновления ...
Но как опытный инженер справится с этим?