Моя придирка скорее в том, что использование терминов, заимствованных из ФП, тут ни к месту, т.к. из ФП ничего не заимствуется в итоге - в ходе всех манипуляций мы получаем обычные объекты...
А если речь идет о том, чтобы полностью конструировать бизнес-логику из таких "объектов-функций", то в таком случае речь идет больше об уходе от ООП, чем о его паттернах. Что-то отдаленно напоминающее процедурное программирование получается ( просто пытаюсь сформулировать, как правильно называется такой подход; если честно, не знаю :D )
Термин Функция-объект (Function Object, или Functor) в контексте объектно-ориентированного программирования появился как естественное развитие концепции функций как объектов из функционального программирования
Такой подход часто используется, например, для событий, коллбеков или обработки команд из UI
Удачи юзнуть "функтор" с зависимостью от EF Core как коллбек на событие, допустим
---
Тульский пряник, это не пряник, потому что уже есть мятный пряник.
Зачем изобретать тульский пряник на базе мятного пряника?
---
Еще раз повторюсь, что идея здравая. Хороший подход, который имеет место быть. Но в объяснении приплетены паттерны совсем из другой оперы с другими свойствами и предназначениями
Я прочитал и предыдущую статью, и эту, и комменты частично. Долго медитировал на счет корректности паттерна. С одной стороны, раскидать логику по разным юзкейсам - это идея здравая. С другой - чувствуется, что что-то не то... И в общем я пришел к выводу, что в статье просто описывается принип SRP: https://habr.com/ru/articles/454290/
Но это не функциональный объект, потому что:
функциональный объект в C# уже есть, это - делегат
таскать внешние зависимости из DI - это в общем-то антипаттерн для ФП; функции должны быть чистыми, иначе шибко их не закомбинируешь
Несмотря на путаницу в терминологии, идея в общем-то здравая имхо. Язык не повернется назвать антипаттерном... Если в фасад обернуть, так - вообще тема. Главное - слишком сильно не увлекаться декомпозицией, т.к. с большим количеством мелких объектов тоже проблематично работать
upd
Мой последний проект состоял из более чем 250 микросервисов, и включал в себя такие группы функций как ETL, Search, RAG, и только в части из них были использованы Function Object
Подтверждаю. В микросервисах может оказаться очень кайфово просто раскидывать по юзкейсам код. Там какой-нибудь MediatR + Minimal Api или FastEndpoints - и в путь. Нет смысла особо что-то инженерить, т.к. архитектурные границы уже были проведены на уровне сервисов
А это значит, что для парсинга законодательных проектов советы в статье не сработают.
Считаю, что это не совсем корректная критика автора. Скрейпинг того или иного ресурса - всегда разный скрипт. Это нормально, что один прием может сработать на одном сайте, но на другом - нет
Советы из статьи в принципе не работают: парсинг не так делается. Я давно жду комментарии и статьи от людей, кто и правда что то такое делает. Со scrapy, желательно.
В принципе, подход автора сработает, если владелец сайта не против, чтобы его спарсили (нет JS, капчи и прочей защиты от ботов, авторизации, щедро раскиданы ARIA-атрибуты). А если владелец сайта против, то лично у меня уже на правовом моменте опускаются руки :D (натыкался на статью на эту тему https://habr.com/ru/articles/545818). Знаю, что через Selenium успешно обходят всё это дело (даже крутых антиботов от Cloudflare). Всякие прокси, сервисы для обхода капч и кастомные драйверы для Selenium сверху прилагаются само собой. Но всё равно сфера скрейпинга в правовом плане мутная. Для себя я решил в неё не соваться. Не уверен даже, что обсуждение инструментов для скрейпинга не попадет в будущем под цензуру по аналогии с VPN. Думаю, по той же причине на хабре и статей не густо
Слежу за эпопеей с ботом самого её начала. Хотел даже посоветовать бота знакомому ролевику. Однако анлаки: он, похоже, удалил группу (возможно, полностью переехал в Дискорд)
Моя придирка скорее в том, что использование терминов, заимствованных из ФП, тут ни к месту, т.к. из ФП ничего не заимствуется в итоге - в ходе всех манипуляций мы получаем обычные объекты...
А если речь идет о том, чтобы полностью конструировать бизнес-логику из таких "объектов-функций", то в таком случае речь идет больше об уходе от ООП, чем о его паттернах. Что-то отдаленно напоминающее процедурное программирование получается ( просто пытаюсь сформулировать, как правильно называется такой подход; если честно, не знаю :D )
Ты сам же :D
Удачи юзнуть "функтор" с зависимостью от EF Core как коллбек на событие, допустим
---
Зачем изобретать тульский пряник на базе мятного пряника?
---
Еще раз повторюсь, что идея здравая. Хороший подход, который имеет место быть. Но в объяснении приплетены паттерны совсем из другой оперы с другими свойствами и предназначениями
Я прочитал и предыдущую статью, и эту, и комменты частично. Долго медитировал на счет корректности паттерна. С одной стороны, раскидать логику по разным юзкейсам - это идея здравая. С другой - чувствуется, что что-то не то... И в общем я пришел к выводу, что в статье просто описывается принип SRP: https://habr.com/ru/articles/454290/
Но это не функциональный объект, потому что:
функциональный объект в C# уже есть, это - делегат
таскать внешние зависимости из DI - это в общем-то антипаттерн для ФП; функции должны быть чистыми, иначе шибко их не закомбинируешь
Несмотря на путаницу в терминологии, идея в общем-то здравая имхо. Язык не повернется назвать антипаттерном... Если в фасад обернуть, так - вообще тема. Главное - слишком сильно не увлекаться декомпозицией, т.к. с большим количеством мелких объектов тоже проблематично работать
upd
Подтверждаю. В микросервисах может оказаться очень кайфово просто раскидывать по юзкейсам код. Там какой-нибудь MediatR + Minimal Api или FastEndpoints - и в путь. Нет смысла особо что-то инженерить, т.к. архитектурные границы уже были проведены на уровне сервисов
Это поисковик, а не браузер )
Считаю, что это не совсем корректная критика автора. Скрейпинг того или иного ресурса - всегда разный скрипт. Это нормально, что один прием может сработать на одном сайте, но на другом - нет
В принципе, подход автора сработает, если владелец сайта не против, чтобы его спарсили (нет JS, капчи и прочей защиты от ботов, авторизации, щедро раскиданы ARIA-атрибуты). А если владелец сайта против, то лично у меня уже на правовом моменте опускаются руки :D (натыкался на статью на эту тему https://habr.com/ru/articles/545818). Знаю, что через Selenium успешно обходят всё это дело (даже крутых антиботов от Cloudflare). Всякие прокси, сервисы для обхода капч и кастомные драйверы для Selenium сверху прилагаются само собой. Но всё равно сфера скрейпинга в правовом плане мутная. Для себя я решил в неё не соваться. Не уверен даже, что обсуждение инструментов для скрейпинга не попадет в будущем под цензуру по аналогии с VPN. Думаю, по той же причине на хабре и статей не густо
Слежу за эпопеей с ботом самого её начала. Хотел даже посоветовать бота знакомому ролевику. Однако анлаки: он, похоже, удалил группу (возможно, полностью переехал в Дискорд)
Желаю-таки найти свою аудиторию ))
Да, думаю, лучше всегда пользоватся Filebeat. Проигнорировал его только потому, что он что-то вроде "необязателен" в отличие от других компонентов