Не, во втором листинге все верно =) здесь подразумевается, что объект Experience умеет обрабатывать push как результата выполнения ExperimentProcedure, так и другого такого же объекта (результат второй операции — добавление всего опыта из передаваемого объекта Experience). Т.е. в функции experiment создается и наполняется объект Experience, который затем добавляется в поле _experience.
Эти два примера эквивалентны по результату своей работы, но во втором листинге функция experiment не обращается к полям объекта Invasion и не редактирует их. Контроль над состоянием объекта находится у функции investage, она же решает, какие поля нужно передать в experiment. Кроме того, в первом листинге метод investigate несет намного меньше смысловой нагрузки, по сравнению с методами updateChosenOnesList и experiment (что на мой взгляд так же является признаком плохого кода). Во втором листинге этот недостаток также исправлен.
Кстати, речь не только об изменении методами состояния объекта (побочных эффектах), но и о том, что приватные методы (хелперы) не должны обращаться к состоянию объекта сами — все свои параметры они получают в качестве аргументов.
Хотя такой принцип и не претендует на универсальность, его, в первую очередь, стоит применять в случаях, когда можно четко сформулировать задачу метода-хелпера (и, соответственно, назвать его).
Все правильно, первый вариант — как не надо.
Вариант возникновения первого примера — результат «неполного» рефакторинга метода по принципу разделения власти.
Второй вариант — как надо.
Преимущества функционального подхода были описаны в разделе «Плюсы».
>но примеры должны быть тривиальными
Опыт показывает, что эта прописная истина все же ускальзывает от некоторых разработчиков, применяющих разделение власти и часто рефакторинг заканчивается разбиением большого метода на несколько маленьких, каждый из которых получает доступ к состоянию объекта. Что, во многом, равносильно добавления комментариев в код.
>По поводу отношения к ООП
Рассмотрено сочетание парадигм ООП и функционального программирования, отсюда название.
>функций… не зависят от внутреннего состояния объекта
«О том и речь. Функции, не зависящие от состояния объекта вообще не являются методами, и непонятно зачем они вообще методы объекта, а не класса. Зачем вообще тогда класс приведен — не ясно.»
Вы правы, их можно отнести к методам класса. Класс нужен для примеров, в обоих случаях модифицируется состояние объекта этого класса — в первом в приватных методах, во втором — в паблик.
Уверен, что 99% процентов мыслей, которые возникнут в моей голове уже кто-то успел подумать и возможно даже изложить в письменном виде и опубликовать.
«И да, первый листинг… грубо говоря не очень удачен.» — спасибо, так и планировалось.
По поводу тривиальности примеров — имхо, но примеры должны быть тривиальными по своей сути поскольку их задачей является упрощение усвоения информации, а не наоборот.
По поводу отношения к ООП — пожалуйста, уточните, потому что есть мнение, что оба приведенных примера соответствуют парадигме ООП по всем трем пунктам.
Изменение аргументов функций — речь здесь не об этом, а о том, что функции (в данном случае приватные методы) не зависят от внутреннего состояния объекта (его полей, если совсем конкретно) и не изменяют его.
Хотя такой принцип и не претендует на универсальность, его, в первую очередь, стоит применять в случаях, когда можно четко сформулировать задачу метода-хелпера (и, соответственно, назвать его).
Вариант возникновения первого примера — результат «неполного» рефакторинга метода по принципу разделения власти.
Второй вариант — как надо.
Преимущества функционального подхода были описаны в разделе «Плюсы».
Опыт показывает, что эта прописная истина все же ускальзывает от некоторых разработчиков, применяющих разделение власти и часто рефакторинг заканчивается разбиением большого метода на несколько маленьких, каждый из которых получает доступ к состоянию объекта. Что, во многом, равносильно добавления комментариев в код.
>По поводу отношения к ООП
Рассмотрено сочетание парадигм ООП и функционального программирования, отсюда название.
>функций… не зависят от внутреннего состояния объекта
«О том и речь. Функции, не зависящие от состояния объекта вообще не являются методами, и непонятно зачем они вообще методы объекта, а не класса. Зачем вообще тогда класс приведен — не ясно.»
Вы правы, их можно отнести к методам класса. Класс нужен для примеров, в обоих случаях модифицируется состояние объекта этого класса — в первом в приватных методах, во втором — в паблик.
«И да, первый листинг… грубо говоря не очень удачен.» — спасибо, так и планировалось.
По поводу отношения к ООП — пожалуйста, уточните, потому что есть мнение, что оба приведенных примера соответствуют парадигме ООП по всем трем пунктам.
Изменение аргументов функций — речь здесь не об этом, а о том, что функции (в данном случае приватные методы) не зависят от внутреннего состояния объекта (его полей, если совсем конкретно) и не изменяют его.