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