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