В статье я привожу пример - когда вы пишите код и вызываете стандартную функцию языка получается ваш код это клиентский код, слои тут не причём.
По поводу слоя Application, соглашусь с вами что код логически больше относится к нему (в некотором смысле я задал тон архитектуре одним классом, да?), но хочу заметить что слои можно называть как угодно, я под Application, например, имею ввиду прослойку между External (внешний мир) и BuisnessLogic(Domain предположу вы бы сказали). Какая разница как называть слои?
Не думаю что ваш переписанный пример проще читать, не вижу смысла что-то доказывать, и каким образом? Трудовую показать?)
Ты можешь обращаться к файловой системе через объект который выражает файловую систему в коде. И опять же с помощью магических методов контролировать работу с ним. Магические методы помогают программно задать логику объекта при работе с ним в клиентском коде. Например (в зависимости от языка): создание, вызов объекта как функцию, вызов как строку, сравнение объектов и еще чуть больше разных операций
Хорошо, согласен, ФП не создает side effect. Побочный эффект присущ по сути любому языку программирования. Но разве тогда не получается что ООП как-раз шаг в сторону по борьбе с побочными эффектами?
Функциональный стиль хорош для работы с данными, параллельных вычислений и минимизации побочных эффектов. - пишет автор Может я не правильно прочитал статью (перевод) https://habr.com/ru/articles/570642/ Но помоему здесь написано про то что функциональное программирование как раз и создает эти side effects
Что программиста, как создателя клиентского кода, можно и нужно контролировать. Когда этот контроль пропадает - получается монолит.
В статье я привожу пример - когда вы пишите код и вызываете стандартную функцию языка получается ваш код это клиентский код, слои тут не причём.
По поводу слоя Application, соглашусь с вами что код логически больше относится к нему (в некотором смысле я задал тон архитектуре одним классом, да?), но хочу заметить что слои можно называть как угодно, я под Application, например, имею ввиду прослойку между External (внешний мир) и BuisnessLogic(Domain предположу вы бы сказали). Какая разница как называть слои?
Не думаю что ваш переписанный пример проще читать, не вижу смысла что-то доказывать, и каким образом? Трудовую показать?)
В названии конструктора и правда ошибся
Образование у меня как раз есть, начинал я свое "вкатывание" с пар по ассемблер и C++
Ты можешь обращаться к файловой системе через объект который выражает файловую систему в коде. И опять же с помощью магических методов контролировать работу с ним. Магические методы помогают программно задать логику объекта при работе с ним в клиентском коде. Например (в зависимости от языка): создание, вызов объекта как функцию, вызов как строку, сравнение объектов и еще чуть больше разных операций
Я не знаю ООП
В ООП можно ограничить изменения данных до 1 файла (класса). Контролировать код на уровне объектов, за счет магических методов например
Логический шаг к возможности контролировать эффекты функций при выполнении программ, на уровне языка программирования
Хотелось бы услышать что-то конструктивное, по существу, тяжело отвечать когда не понятно о чем вы говорите.
Хорошо, согласен, ФП не создает side effect. Побочный эффект присущ по сути любому языку программирования. Но разве тогда не получается что ООП как-раз шаг в сторону по борьбе с побочными эффектами?
Каким образом?
Функциональный стиль хорош для работы с данными, параллельных вычислений и минимизации побочных эффектов.- пишет авторМожет я не правильно прочитал статью (перевод) https://habr.com/ru/articles/570642/ Но помоему здесь написано про то что функциональное программирование как раз и создает эти side effects