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