#ооп — Public Fediverse posts

Первые отзывы на новинки о System Design

Привет, Хаброжители! Спешим поделится с вами первыми рецензиями на предзаказы: «System Design. Проектирование мобильных систем. Подготовка к сложному интервью» и «Object Oriented Design. Подготовка к сложному интервью».

https://habr.com/ru/companies/piter/articles/1037222/

#system_design #подготовка_к_собеседованию #техническое_собеседование #ood #проектирование_систем #предзаказ #ооп

Первые отзывы на новинки о System Design

Привет, Хаброжители! Спешим поделится с вами первыми рецензиями на предзаказы: «System Design. Проектирование мобильных систем. Подготовка к сложному интервью» и «Object Oriented Design. Подготовка к сложному интервью».

https://habr.com/ru/companies/piter/articles/1037222/

#system_design #подготовка_к_собеседованию #техническое_собеседование #ood #проектирование_систем #предзаказ #ооп

Первые отзывы на новинки о System Design

Привет, Хаброжители! Спешим поделится с вами первыми рецензиями на предзаказы: «System Design. Проектирование мобильных систем. Подготовка к сложному интервью» и «Object Oriented Design. Подготовка к сложному интервью».

https://habr.com/ru/companies/piter/articles/1037222/

#system_design #подготовка_к_собеседованию #техническое_собеседование #ood #проектирование_систем #предзаказ #ооп

Интеграционный хаб в SAP HR — строим гибкость в ритме трансформаций

Как с помощью Clean ABAP и Low-code ускорить выгрузки в 5 раз Привет, Хабр! Меня зовут Дмитрий, я работаю ведущим разработчиком в Lenta tech («Группа Лента»). В этой статье я разберу архитектуру решения, где технические инструменты — наследование классов и абстрактные типы данных — работают на конкретные бизнес-цели. Я поделюсь нашими принципами по созданию гибкого ядра, способного за считанные дни подключать новых потребителей без риска для стабильности системы.

https://habr.com/ru/companies/lentatech/articles/1032614/

#SAP #ABAP #Архитектура_ИТсистем #Импортозамещение #ООП #Интеграция_данных #ретейл #lowcode #ttm #hr_tech

Интеграционный хаб в SAP HR — строим гибкость в ритме трансформаций

Как с помощью Clean ABAP и Low-code ускорить выгрузки в 5 раз Привет, Хабр! Меня зовут Дмитрий, я работаю ведущим разработчиком в Lenta tech («Группа Лента»). В этой статье я разберу архитектуру решения, где технические инструменты — наследование классов и абстрактные типы данных — работают на конкретные бизнес-цели. Я поделюсь нашими принципами по созданию гибкого ядра, способного за считанные дни подключать новых потребителей без риска для стабильности системы.

https://habr.com/ru/companies/lentatech/articles/1032614/

#SAP #ABAP #Архитектура_ИТсистем #Импортозамещение #ООП #Интеграция_данных #ретейл #lowcode #ttm #hr_tech

Интеграционный хаб в SAP HR — строим гибкость в ритме трансформаций

Как с помощью Clean ABAP и Low-code ускорить выгрузки в 5 раз Привет, Хабр! Меня зовут Дмитрий, я работаю ведущим разработчиком в Lenta tech («Группа Лента»). В этой статье я разберу архитектуру решения, где технические инструменты — наследование классов и абстрактные типы данных — работают на конкретные бизнес-цели. Я поделюсь нашими принципами по созданию гибкого ядра, способного за считанные дни подключать новых потребителей без риска для стабильности системы.

https://habr.com/ru/companies/lentatech/articles/1032614/

#SAP #ABAP #Архитектура_ИТсистем #Импортозамещение #ООП #Интеграция_данных #ретейл #lowcode #ttm #hr_tech

Интеграционный хаб в SAP HR — строим гибкость в ритме трансформаций

Как с помощью Clean ABAP и Low-code ускорить выгрузки в 5 раз Привет, Хабр! Меня зовут Дмитрий, я работаю ведущим разработчиком в Lenta tech («Группа Лента»). В этой статье я разберу архитектуру решения, где технические инструменты — наследование классов и абстрактные типы данных — работают на конкретные бизнес-цели. Я поделюсь нашими принципами по созданию гибкого ядра, способного за считанные дни подключать новых потребителей без риска для стабильности системы.

https://habr.com/ru/companies/lentatech/articles/1032614/

#SAP #ABAP #Архитектура_ИТсистем #Импортозамещение #ООП #Интеграция_данных #ретейл #lowcode #ttm #hr_tech

Чистая архитектура на практике: перестаём ломать сервис при каждом релизе

У вас небольшой релиз. Вы меняете пару строк кода, выкатываете обновление - и через несколько минут сервис начинает отдавать странные ошибки. Баги появляются в местах, которые вы вообще не трогали. Знакомо? Обычно проблема не в конкретном изменении, а в архитектурной связанности системы: инфраструктурные детали начинают протекать в бизнес-логику, и зависимости между компонентами становятся слишком плотными. Разберём это на примерах. Примеры будут псевдореальные, иначе статья быстро превратится в книгу. Посмотрите на функцию загрузки инвойса:

https://habr.com/ru/articles/1034758/

#clean_architecture #clean_code #architecture #программирование #проектирование_систем #шаблоны_проектирования #ооп #hexagonal_architecture #grasp #solid

Чистая архитектура на практике: перестаём ломать сервис при каждом релизе

У вас небольшой релиз. Вы меняете пару строк кода, выкатываете обновление - и через несколько минут сервис начинает отдавать странные ошибки. Баги появляются в местах, которые вы вообще не трогали. Знакомо? Обычно проблема не в конкретном изменении, а в архитектурной связанности системы: инфраструктурные детали начинают протекать в бизнес-логику, и зависимости между компонентами становятся слишком плотными. Разберём это на примерах. Примеры будут псевдореальные, иначе статья быстро превратится в книгу. Посмотрите на функцию загрузки инвойса:

https://habr.com/ru/articles/1034758/

#clean_architecture #clean_code #architecture #программирование #проектирование_систем #шаблоны_проектирования #ооп #hexagonal_architecture #grasp #solid

Чистая архитектура на практике: перестаём ломать сервис при каждом релизе

У вас небольшой релиз. Вы меняете пару строк кода, выкатываете обновление - и через несколько минут сервис начинает отдавать странные ошибки. Баги появляются в местах, которые вы вообще не трогали. Знакомо? Обычно проблема не в конкретном изменении, а в архитектурной связанности системы: инфраструктурные детали начинают протекать в бизнес-логику, и зависимости между компонентами становятся слишком плотными. Разберём это на примерах. Примеры будут псевдореальные, иначе статья быстро превратится в книгу. Посмотрите на функцию загрузки инвойса:

https://habr.com/ru/articles/1034758/

#clean_architecture #clean_code #architecture #программирование #проектирование_систем #шаблоны_проектирования #ооп #hexagonal_architecture #grasp #solid

Чистая архитектура на практике: перестаём ломать сервис при каждом релизе

У вас небольшой релиз. Вы меняете пару строк кода, выкатываете обновление - и через несколько минут сервис начинает отдавать странные ошибки. Баги появляются в местах, которые вы вообще не трогали. Знакомо? Обычно проблема не в конкретном изменении, а в архитектурной связанности системы: инфраструктурные детали начинают протекать в бизнес-логику, и зависимости между компонентами становятся слишком плотными. Разберём это на примерах. Примеры будут псевдореальные, иначе статья быстро превратится в книгу. Посмотрите на функцию загрузки инвойса:

https://habr.com/ru/articles/1034758/

#clean_architecture #clean_code #architecture #программирование #проектирование_систем #шаблоны_проектирования #ооп #hexagonal_architecture #grasp #solid

Переопределение классов ядра Joomla с помощью плагина на примере MVCFactory

Разработчики сайтов, веб-мастера, рассматривая Joomla как CMS, чаще всего используют компоненты ядра такими, какие они есть. Но компоненты ядра, обеспечивающие CRUD-ы в Joomla, следует рассматривать ещё и как примеры использования Joomla в качестве фреймворка. Иногда реалии проекта таковы, что требуется внести изменения именно в логику классов ядра Joomla. Я покажу это на нескольких примерах: как исхитрялись раньше и какие возможности появились в современных версиях Joomla. Сразу оговорюсь: речь не о том, чтобы править файлы ядра. Это плохая идея почти всегда. При обновлении Joomla такие изменения будут потеряны, а сопровождать их потом придётся вручную. Речь о другом: как изменить точку создания MVC-классов компонента через плагин и DI-контейнер, не залезая в core-файлы. Ну и приятный бонус - Joomla-археология и немного красивого и ужасного треша из практики 😎

https://habr.com/ru/articles/1033646/

#joomla #joomla_6 #mvcfactory #mvc #override #декоратор #ооп

Полный гайд по dunder-методам в Python (от новичка до профи)

В Python всё — объект. Но как язык понимает, что делать при сложении двух классов через +, вызове len() или обращении к несуществующему атрибуту? Вся магия скрыта под капотом dunder-методов. Мы собрали полный гайд для разработчиков любого уровня: от правильной инициализации и перегрузки операторов до создания собственных дескрипторов, контекстных менеджеров и жесткой оптимизации памяти через slots . Никакой воды, только практика, живые примеры и то, что реально спрашивают на собеседованиях.

https://habr.com/ru/articles/1033432/

#ython #ООП #dunderметоды #магические_методы #метапрограммирование #дескрипторы #итераторы #генераторы #контекстные_менеджеры #Python_3

Полный гайд по dunder-методам в Python (от новичка до профи)

В Python всё — объект. Но как язык понимает, что делать при сложении двух классов через +, вызове len() или обращении к несуществующему атрибуту? Вся магия скрыта под капотом dunder-методов. Мы собрали полный гайд для разработчиков любого уровня: от правильной инициализации и перегрузки операторов до создания собственных дескрипторов, контекстных менеджеров и жесткой оптимизации памяти через slots . Никакой воды, только практика, живые примеры и то, что реально спрашивают на собеседованиях.

https://habr.com/ru/articles/1033432/

#ython #ООП #dunderметоды #магические_методы #метапрограммирование #дескрипторы #итераторы #генераторы #контекстные_менеджеры #Python_3

Полный гайд по dunder-методам в Python (от новичка до профи)

В Python всё — объект. Но как язык понимает, что делать при сложении двух классов через +, вызове len() или обращении к несуществующему атрибуту? Вся магия скрыта под капотом dunder-методов. Мы собрали полный гайд для разработчиков любого уровня: от правильной инициализации и перегрузки операторов до создания собственных дескрипторов, контекстных менеджеров и жесткой оптимизации памяти через slots . Никакой воды, только практика, живые примеры и то, что реально спрашивают на собеседованиях.

https://habr.com/ru/articles/1033432/

#ython #ООП #dunderметоды #магические_методы #метапрограммирование #дескрипторы #итераторы #генераторы #контекстные_менеджеры #Python_3

Полный гайд по dunder-методам в Python (от новичка до профи)

В Python всё — объект. Но как язык понимает, что делать при сложении двух классов через +, вызове len() или обращении к несуществующему атрибуту? Вся магия скрыта под капотом dunder-методов. Мы собрали полный гайд для разработчиков любого уровня: от правильной инициализации и перегрузки операторов до создания собственных дескрипторов, контекстных менеджеров и жесткой оптимизации памяти через slots . Никакой воды, только практика, живые примеры и то, что реально спрашивают на собеседованиях.

https://habr.com/ru/articles/1033432/

#ython #ООП #dunderметоды #магические_методы #метапрограммирование #дескрипторы #итераторы #генераторы #контекстные_менеджеры #Python_3

Объекты и классы — дар божий или проклятие

Я давно вынашивал желание написать эту статью. И, наверное, мне бы стоило потратить некоторое время на то, чтобы написать её чуть более структурно и продуманно, но, пожалуй, я её в таком случае вообще не напишу, так что - статья будет ad hock, прям from the top of my mind. Начнём с того, что в обсуждениях объектного программирования бытуют несколько популярных мнений

https://habr.com/ru/articles/1025200/

#ооп #фп #структурное_программирование #спагеттикод #человек

Объекты и классы — дар божий или проклятие

Я давно вынашивал желание написать эту статью. И, наверное, мне бы стоило потратить некоторое время на то, чтобы написать её чуть более структурно и продуманно, но, пожалуй, я её в таком случае вообще не напишу, так что - статья будет ad hock, прям from the top of my mind. Начнём с того, что в обсуждениях объектного программирования бытуют несколько популярных мнений

https://habr.com/ru/articles/1025200/

#ооп #фп #структурное_программирование #спагеттикод #человек

Объекты и классы — дар божий или проклятие

Я давно вынашивал желание написать эту статью. И, наверное, мне бы стоило потратить некоторое время на то, чтобы написать её чуть более структурно и продуманно, но, пожалуй, я её в таком случае вообще не напишу, так что - статья будет ad hock, прям from the top of my mind. Начнём с того, что в обсуждениях объектного программирования бытуют несколько популярных мнений

https://habr.com/ru/articles/1025200/

#ооп #фп #структурное_программирование #спагеттикод #человек

Объекты и классы — дар божий или проклятие

Я давно вынашивал желание написать эту статью. И, наверное, мне бы стоило потратить некоторое время на то, чтобы написать её чуть более структурно и продуманно, но, пожалуй, я её в таком случае вообще не напишу, так что - статья будет ad hock, прям from the top of my mind. Начнём с того, что в обсуждениях объектного программирования бытуют несколько популярных мнений

https://habr.com/ru/articles/1025200/

#ооп #фп #структурное_программирование #спагеттикод #человек

Создаем Java обертку для C++ класса в Android приложении, а также реализуем обратные вызовы из нэйтива

Кратко расскажу о себе и о том, зачем возникла необходимость в подобном. Я более десяти лет пишу приложения под Android, около 5 лет под IOS, и сейчас переношу свои наработки под десктопы. Приложения мои предназначены для сисадминов, это SSH клиент, сетевые сканеры и тд. В общем, самое сложное - не сам интерфейс, а то, что под капотом. Когда я лишь начинал, я думал, что остановлюсь на платформе Android и стал пилить все на Java. Но затем осознал свою ошибку и исправил ее. На данный момент все мои приложения состоят из двух частей: общего для всех систем ядра на С++ и платформозависимого интерфейса, написанного на Java/Swift/C++ в зависимости от системы. Оговорюсь сразу, эта статья будет лишь своего рода вступлением. Я покажу, как работать с объектно-ориентированным кодом на C++ в Java оболочке (в JNI нам доступен экспорт С функций). Инициализировать объект, делать из него вызовы, удалять, при этом имея аналогичный класс в оболочке, будто бы наш код был написан на Java. Задача эта не слишком сложная, но прежде чем опытные прогеры закрыли эту статью, я оговорюсь, что в следующей части мы уже будем работать с каллбэками - вызовами Java листенеров из нашего С++ кода, а вот это уже задача совсем нетривиальная, требующая понимания работы JNI и Dalvik. Но обо всем по порядку. Итак, у нас есть некий CPP класс и Java оболочка. Через JNI мы можем вызывать только С-функции, то есть не объектный код. Так как же нам работать с ООП? Главная проблема - не столько вызовы, сколько хранение адреса объекта нативного класса. Лично для себя я нашел решение - хранить его в Java классе, как long. То есть, у нас получается приблизительно такой код:

https://habr.com/ru/articles/1017486/

#Java #C++ #ООП #Dalvik #JNI #android

Создаем Java обертку для C++ класса в Android приложении, а также реализуем обратные вызовы из нэйтива

Кратко расскажу о себе и о том, зачем возникла необходимость в подобном. Я более десяти лет пишу приложения под Android, около 5 лет под IOS, и сейчас переношу свои наработки под десктопы. Приложения мои предназначены для сисадминов, это SSH клиент, сетевые сканеры и тд. В общем, самое сложное - не сам интерфейс, а то, что под капотом. Когда я лишь начинал, я думал, что остановлюсь на платформе Android и стал пилить все на Java. Но затем осознал свою ошибку и исправил ее. На данный момент все мои приложения состоят из двух частей: общего для всех систем ядра на С++ и платформозависимого интерфейса, написанного на Java/Swift/C++ в зависимости от системы. Оговорюсь сразу, эта статья будет лишь своего рода вступлением. Я покажу, как работать с объектно-ориентированным кодом на C++ в Java оболочке (в JNI нам доступен экспорт С функций). Инициализировать объект, делать из него вызовы, удалять, при этом имея аналогичный класс в оболочке, будто бы наш код был написан на Java. Задача эта не слишком сложная, но прежде чем опытные прогеры закрыли эту статью, я оговорюсь, что в следующей части мы уже будем работать с каллбэками - вызовами Java листенеров из нашего С++ кода, а вот это уже задача совсем нетривиальная, требующая понимания работы JNI и Dalvik. Но обо всем по порядку. Итак, у нас есть некий CPP класс и Java оболочка. Через JNI мы можем вызывать только С-функции, то есть не объектный код. Так как же нам работать с ООП? Главная проблема - не столько вызовы, сколько хранение адреса объекта нативного класса. Лично для себя я нашел решение - хранить его в Java классе, как long. То есть, у нас получается приблизительно такой код:

https://habr.com/ru/articles/1017486/

#Java #C++ #ООП #Dalvik #JNI #android

Создаем Java обертку для C++ класса в Android приложении, а также реализуем обратные вызовы из нэйтива

Кратко расскажу о себе и о том, зачем возникла необходимость в подобном. Я более десяти лет пишу приложения под Android, около 5 лет под IOS, и сейчас переношу свои наработки под десктопы. Приложения мои предназначены для сисадминов, это SSH клиент, сетевые сканеры и тд. В общем, самое сложное - не сам интерфейс, а то, что под капотом. Когда я лишь начинал, я думал, что остановлюсь на платформе Android и стал пилить все на Java. Но затем осознал свою ошибку и исправил ее. На данный момент все мои приложения состоят из двух частей: общего для всех систем ядра на С++ и платформозависимого интерфейса, написанного на Java/Swift/C++ в зависимости от системы. Оговорюсь сразу, эта статья будет лишь своего рода вступлением. Я покажу, как работать с объектно-ориентированным кодом на C++ в Java оболочке (в JNI нам доступен экспорт С функций). Инициализировать объект, делать из него вызовы, удалять, при этом имея аналогичный класс в оболочке, будто бы наш код был написан на Java. Задача эта не слишком сложная, но прежде чем опытные прогеры закрыли эту статью, я оговорюсь, что в следующей части мы уже будем работать с каллбэками - вызовами Java листенеров из нашего С++ кода, а вот это уже задача совсем нетривиальная, требующая понимания работы JNI и Dalvik. Но обо всем по порядку. Итак, у нас есть некий CPP класс и Java оболочка. Через JNI мы можем вызывать только С-функции, то есть не объектный код. Так как же нам работать с ООП? Главная проблема - не столько вызовы, сколько хранение адреса объекта нативного класса. Лично для себя я нашел решение - хранить его в Java классе, как long. То есть, у нас получается приблизительно такой код:

https://habr.com/ru/articles/1017486/

#Java #C++ #ООП #Dalvik #JNI #android

Создаем Java обертку для C++ класса в Android приложении, а также реализуем обратные вызовы из нэйтива

Кратко расскажу о себе и о том, зачем возникла необходимость в подобном. Я более десяти лет пишу приложения под Android, около 5 лет под IOS, и сейчас переношу свои наработки под десктопы. Приложения мои предназначены для сисадминов, это SSH клиент, сетевые сканеры и тд. В общем, самое сложное - не сам интерфейс, а то, что под капотом. Когда я лишь начинал, я думал, что остановлюсь на платформе Android и стал пилить все на Java. Но затем осознал свою ошибку и исправил ее. На данный момент все мои приложения состоят из двух частей: общего для всех систем ядра на С++ и платформозависимого интерфейса, написанного на Java/Swift/C++ в зависимости от системы. Оговорюсь сразу, эта статья будет лишь своего рода вступлением. Я покажу, как работать с объектно-ориентированным кодом на C++ в Java оболочке (в JNI нам доступен экспорт С функций). Инициализировать объект, делать из него вызовы, удалять, при этом имея аналогичный класс в оболочке, будто бы наш код был написан на Java. Задача эта не слишком сложная, но прежде чем опытные прогеры закрыли эту статью, я оговорюсь, что в следующей части мы уже будем работать с каллбэками - вызовами Java листенеров из нашего С++ кода, а вот это уже задача совсем нетривиальная, требующая понимания работы JNI и Dalvik. Но обо всем по порядку. Итак, у нас есть некий CPP класс и Java оболочка. Через JNI мы можем вызывать только С-функции, то есть не объектный код. Так как же нам работать с ООП? Главная проблема - не столько вызовы, сколько хранение адреса объекта нативного класса. Лично для себя я нашел решение - хранить его в Java классе, как long. То есть, у нас получается приблизительно такой код:

https://habr.com/ru/articles/1017486/

#Java #C++ #ООП #Dalvik #JNI #android

Лингвистическая относительность в программировании — как наше мышление определяет выбор языка и стиль кодирования

Поводом к написанию предыдущей статьи «Шаблоны и принципы деления кода на классы» послужил случай с начинающим программистом, который обратился ко мне за помощью. Однако та история получила неожиданное продолжение, ставшее, в свою очередь, одной из предпосылок уже для этой статьи. И видимо, волей судьбы или просто по забавному стечению обстоятельств, эта история оказалась напрямую связана с комментариями к первой статье, где в ходе жаркого диалога я затронул тему мышления и восприятия кода разработчиком. Так родилась идея поделиться накопившимися за 10-летний стаж наблюдениями и плодами размышлений: - Как стиль написания кода отражает образ мышления разработчика. - Как разработчики воспринимают код программы. - Почему один язык программирования, что называется, «заходит», а другой - нет.

https://habr.com/ru/companies/cinimex/articles/1013914/

#коддинг #java #python #программирование #функциональное_программирование #процедурное_программирование #ооп #ооп_программирование #языки_программирования #языки

Изучаем ООП на C++! В выпуске — объектная модель, инкапсуляция и жизненный цикл объектов с понятными примерами. Отлично для студентов и практиков, кто хочет укрепить базу и писать код грамотнее. Загляните и прокачайте навыки! #cpp #Cplusplus #ООП #OOP #Инкапсуляция #ОбъектнаяМодель #Программирование #Russian
https://video.lernado-base.ru/videos/watch/83a10b29-25f3-489a-a8e1-69baece7f479

Изучаем ООП на C++! В выпуске — объектная модель, инкапсуляция и жизненный цикл объектов с понятными примерами. Отлично для студентов и практиков, кто хочет укрепить базу и писать код грамотнее. Загляните и прокачайте навыки! #cpp #Cplusplus #ООП #OOP #Инкапсуляция #ОбъектнаяМодель #Программирование #Russian
https://video.lernado-base.ru/videos/watch/83a10b29-25f3-489a-a8e1-69baece7f479

Попытка имитация расширения модуля Elixir как класса ООП

1. Мотивация Как я писал в предыдущей статье https://habr.com/ru/articles/1002748/ при разработке прототипа системы взаимодействующих движков первыми движками оказались тактовые генераторы, задающие время и синхронизацию коллектива движков. Остальные рабочие движки можно было бы стандартно реализовать с помощью нескольких специфических серверов движков, но мне захотелось сделать всё по правилам ООП и испытать выразительную мощь языка Elixir. Т.е. дальнейшую разработку предполагается провести в рамках парадигмы ООП, расширяя модуль «класса» тактовых генераторов. 2. Предварительное исследование В начале поиска решения был расчет на механизм Поведения (behaviour) Elixir. Поэтому более внимательно перечитал учебную литературу, и выяснил, что этот инструмент для схожей, но другой задачи: задание контракта поведения и проверка на этапе компиляции реализации модулем требуемых функций обратного вызова. Ещё я потратил много времени на поиск в Интернете, как коллеги расширяют модули Elixir аля классы ООП и нашел только один источник конференции по этому вопросу [1]. Но я решил вначале самому попробовать пройти путь квеста, чтобы сравнить потом свой результат с чужими. Забегая вперед, могу сказать, что одно решения [1#9] с конференции почти совпало с моим, но там отсутствуют обобщение и выводы, которые я собираюсь вам сообщить в конце. Справка : В статье невольно производится сопоставление ООП и Elixir, из чего можно сделать вывод, что я отношу Elixir к функциональным языкам. Формально это так и есть, но на деле я вслед за ерлангелистом Сашей Юрич [2] расцениваю Elixir преимущественно языком акторов.

https://habr.com/ru/articles/1007648/

#elixirlang #elixir_otp #ооп

Агглютинативный код: почему будущее IT требует смены лингвистического фундамента

Каждые несколько лет IT-индустрия переживает очередной ренессанс. Мы пишем новые языки программирования - Rust для безопасной работы с памятью, Go для идеальной конкурентности, Swift для экосистемности. Мы плодим новые фреймворки, стандарты и сетевые протоколы, пытаясь превзойти существующие ограничения. Но в погоне за оптимизацией мы не замечаем главного: мы продолжаем строить новые "небоскребы" на старом, потрескавшемся логическом фундаменте. И этот фундамент - это не кремний и не машинный код. Это естественный человеческий язык, на котором думают создатели этих IT-технологий. Проблема современного "зоопарка" технологий, усложнения синтаксиса и бесконечных архитектурных компромиссов кроется в том, что мы перетащили баги человеческой речи в парадигмы программирования. Не понимая, что этот лингвистический фундамент и есть наше главное ограничение.

https://habr.com/ru/articles/1002926/

#архитектура_систем #парадигмы_программирования #ооп #system_design #лингвистика #алгоритмы #агглютинативные_языки #qazna #orda

Агглютинативный код: почему будущее IT требует смены лингвистического фундамента

Каждые несколько лет IT-индустрия переживает очередной ренессанс. Мы пишем новые языки программирования - Rust для безопасной работы с памятью, Go для идеальной конкурентности, Swift для экосистемности. Мы плодим новые фреймворки, стандарты и сетевые протоколы, пытаясь превзойти существующие ограничения. Но в погоне за оптимизацией мы не замечаем главного: мы продолжаем строить новые "небоскребы" на старом, потрескавшемся логическом фундаменте. И этот фундамент - это не кремний и не машинный код. Это естественный человеческий язык, на котором думают создатели этих IT-технологий. Проблема современного "зоопарка" технологий, усложнения синтаксиса и бесконечных архитектурных компромиссов кроется в том, что мы перетащили баги человеческой речи в парадигмы программирования. Не понимая, что этот лингвистический фундамент и есть наше главное ограничение.

https://habr.com/ru/articles/1002926/

#архитектура_систем #парадигмы_программирования #ооп #system_design #лингвистика #алгоритмы #агглютинативные_языки #qazna #orda

Агглютинативный код: почему будущее IT требует смены лингвистического фундамента

Каждые несколько лет IT-индустрия переживает очередной ренессанс. Мы пишем новые языки программирования - Rust для безопасной работы с памятью, Go для идеальной конкурентности, Swift для экосистемности. Мы плодим новые фреймворки, стандарты и сетевые протоколы, пытаясь превзойти существующие ограничения. Но в погоне за оптимизацией мы не замечаем главного: мы продолжаем строить новые "небоскребы" на старом, потрескавшемся логическом фундаменте. И этот фундамент - это не кремний и не машинный код. Это естественный человеческий язык, на котором думают создатели этих IT-технологий. Проблема современного "зоопарка" технологий, усложнения синтаксиса и бесконечных архитектурных компромиссов кроется в том, что мы перетащили баги человеческой речи в парадигмы программирования. Не понимая, что этот лингвистический фундамент и есть наше главное ограничение.

https://habr.com/ru/articles/1002926/

#архитектура_систем #парадигмы_программирования #ооп #system_design #лингвистика #алгоритмы #агглютинативные_языки #qazna #orda

Агглютинативный код: почему будущее IT требует смены лингвистического фундамента

Каждые несколько лет IT-индустрия переживает очередной ренессанс. Мы пишем новые языки программирования - Rust для безопасной работы с памятью, Go для идеальной конкурентности, Swift для экосистемности. Мы плодим новые фреймворки, стандарты и сетевые протоколы, пытаясь превзойти существующие ограничения. Но в погоне за оптимизацией мы не замечаем главного: мы продолжаем строить новые "небоскребы" на старом, потрескавшемся логическом фундаменте. И этот фундамент - это не кремний и не машинный код. Это естественный человеческий язык, на котором думают создатели этих IT-технологий. Проблема современного "зоопарка" технологий, усложнения синтаксиса и бесконечных архитектурных компромиссов кроется в том, что мы перетащили баги человеческой речи в парадигмы программирования. Не понимая, что этот лингвистический фундамент и есть наше главное ограничение.

https://habr.com/ru/articles/1002926/

#архитектура_систем #парадигмы_программирования #ооп #system_design #лингвистика #алгоритмы #агглютинативные_языки #qazna #orda

Связывание абстрактных классов со свойствами в python

В данной статье хочу поделиться своим опытом по абстрактным классам. Думаю это будет полезно как разработчикам, только начинающим свой путь, так и уже имеющим опыт. В материале можно посмотреть, как изящно связать свойства и абстрактные классы с реализацией принципа DRY . Для начал кратко пробежимся по определениями и терминам, и далее ответим на вопросы, которые могут логично вытекать из этих определений. Абстрактные классы - это базовые классы, определяющие каркас с методами, обязательными для реализации в наследниках и служащими для создания интерфейсов, однако сами экземпляры таких классов создать нельзя. Абстрактные методы - методы с декоратором @abstractmethod, которые обязаны быть реализованы в дочерних классах. Абстрактный класс может содержать как обычные, так и абстрактные методы. Свойство - реализуется через декораторы @property (для чтения) и @<name>.setter (для изменения и валидации) обеспечивая инкапсуляцию, делая API удобным, при этом позволяя менять внутреннюю реализацию без изменения внешнего кода.

https://habr.com/ru/articles/1002538/

#Абстрактный_класс #свойство #python #property #setter #ООП #dry #наследование_в_python #абстрактные_классы #валидация_данных

Связывание абстрактных классов со свойствами в python

В данной статье хочу поделиться своим опытом по абстрактным классам. Думаю это будет полезно как разработчикам, только начинающим свой путь, так и уже имеющим опыт. В материале можно посмотреть, как изящно связать свойства и абстрактные классы с реализацией принципа DRY . Для начал кратко пробежимся по определениями и терминам, и далее ответим на вопросы, которые могут логично вытекать из этих определений. Абстрактные классы - это базовые классы, определяющие каркас с методами, обязательными для реализации в наследниках и служащими для создания интерфейсов, однако сами экземпляры таких классов создать нельзя. Абстрактные методы - методы с декоратором @abstractmethod, которые обязаны быть реализованы в дочерних классах. Абстрактный класс может содержать как обычные, так и абстрактные методы. Свойство - реализуется через декораторы @property (для чтения) и @<name>.setter (для изменения и валидации) обеспечивая инкапсуляцию, делая API удобным, при этом позволяя менять внутреннюю реализацию без изменения внешнего кода.

https://habr.com/ru/articles/1002538/

#Абстрактный_класс #свойство #python #property #setter #ООП #dry #наследование_в_python #абстрактные_классы #валидация_данных

Связывание абстрактных классов со свойствами в python

В данной статье хочу поделиться своим опытом по абстрактным классам. Думаю это будет полезно как разработчикам, только начинающим свой путь, так и уже имеющим опыт. В материале можно посмотреть, как изящно связать свойства и абстрактные классы с реализацией принципа DRY . Для начал кратко пробежимся по определениями и терминам, и далее ответим на вопросы, которые могут логично вытекать из этих определений. Абстрактные классы - это базовые классы, определяющие каркас с методами, обязательными для реализации в наследниках и служащими для создания интерфейсов, однако сами экземпляры таких классов создать нельзя. Абстрактные методы - методы с декоратором @abstractmethod, которые обязаны быть реализованы в дочерних классах. Абстрактный класс может содержать как обычные, так и абстрактные методы. Свойство - реализуется через декораторы @property (для чтения) и @<name>.setter (для изменения и валидации) обеспечивая инкапсуляцию, делая API удобным, при этом позволяя менять внутреннюю реализацию без изменения внешнего кода.

https://habr.com/ru/articles/1002538/

#Абстрактный_класс #свойство #python #property #setter #ООП #dry #наследование_в_python #абстрактные_классы #валидация_данных

Связывание абстрактных классов со свойствами в python

В данной статье хочу поделиться своим опытом по абстрактным классам. Думаю это будет полезно как разработчикам, только начинающим свой путь, так и уже имеющим опыт. В материале можно посмотреть, как изящно связать свойства и абстрактные классы с реализацией принципа DRY . Для начал кратко пробежимся по определениями и терминам, и далее ответим на вопросы, которые могут логично вытекать из этих определений. Абстрактные классы - это базовые классы, определяющие каркас с методами, обязательными для реализации в наследниках и служащими для создания интерфейсов, однако сами экземпляры таких классов создать нельзя. Абстрактные методы - методы с декоратором @abstractmethod, которые обязаны быть реализованы в дочерних классах. Абстрактный класс может содержать как обычные, так и абстрактные методы. Свойство - реализуется через декораторы @property (для чтения) и @<name>.setter (для изменения и валидации) обеспечивая инкапсуляцию, делая API удобным, при этом позволяя менять внутреннюю реализацию без изменения внешнего кода.

https://habr.com/ru/articles/1002538/

#Абстрактный_класс #свойство #python #property #setter #ООП #dry #наследование_в_python #абстрактные_классы #валидация_данных

Canvas-конфетти без библиотек: пишем систему частиц и физику на чистом JS

Привет! Я Сергей, разработчик. Когда мне понадобилась легкая анимация лайка в стиле YouTube, я столкнулся с проблемой: готовые решения либо слишком тяжелые, либо плохо дружат с прозрачностью в браузерах. Не желая идти на компромиссы, я реализовал систему анимаций на Canvas. В статье поделюсь опытом создания частиц и физики на чистом JS, а также бегло разберу встроенные инструменты браузера для таких задач. Мы будем делать схематичную анимацию фейерверков и конфетти по нажатию на кнопку при помощи JS. Изученные принципы универсальны для любого ЯП. Нам понадобится немного знаний ООП, тригонометрии, физики и совсем чуть-чуть геометрии. Вот что получится в итоге:

https://habr.com/ru/articles/1001462/

#javascript #canvas #HTML5_Canvas #Система_частиц #Чистый_JS #ООП #физика_в_Web #анимация_в_Web

Canvas-конфетти без библиотек: пишем систему частиц и физику на чистом JS

Привет! Я Сергей, разработчик. Когда мне понадобилась легкая анимация лайка в стиле YouTube, я столкнулся с проблемой: готовые решения либо слишком тяжелые, либо плохо дружат с прозрачностью в браузерах. Не желая идти на компромиссы, я реализовал систему анимаций на Canvas. В статье поделюсь опытом создания частиц и физики на чистом JS, а также бегло разберу встроенные инструменты браузера для таких задач. Мы будем делать схематичную анимацию фейерверков и конфетти по нажатию на кнопку при помощи JS. Изученные принципы универсальны для любого ЯП. Нам понадобится немного знаний ООП, тригонометрии, физики и совсем чуть-чуть геометрии. Вот что получится в итоге:

https://habr.com/ru/articles/1001462/

#javascript #canvas #HTML5_Canvas #Система_частиц #Чистый_JS #ООП #физика_в_Web #анимация_в_Web

Canvas-конфетти без библиотек: пишем систему частиц и физику на чистом JS

Привет! Я Сергей, разработчик. Когда мне понадобилась легкая анимация лайка в стиле YouTube, я столкнулся с проблемой: готовые решения либо слишком тяжелые, либо плохо дружат с прозрачностью в браузерах. Не желая идти на компромиссы, я реализовал систему анимаций на Canvas. В статье поделюсь опытом создания частиц и физики на чистом JS, а также бегло разберу встроенные инструменты браузера для таких задач. Мы будем делать схематичную анимацию фейерверков и конфетти по нажатию на кнопку при помощи JS. Изученные принципы универсальны для любого ЯП. Нам понадобится немного знаний ООП, тригонометрии, физики и совсем чуть-чуть геометрии. Вот что получится в итоге:

https://habr.com/ru/articles/1001462/

#javascript #canvas #HTML5_Canvas #Система_частиц #Чистый_JS #ООП #физика_в_Web #анимация_в_Web

Canvas-конфетти без библиотек: пишем систему частиц и физику на чистом JS

Привет! Я Сергей, разработчик. Когда мне понадобилась легкая анимация лайка в стиле YouTube, я столкнулся с проблемой: готовые решения либо слишком тяжелые, либо плохо дружат с прозрачностью в браузерах. Не желая идти на компромиссы, я реализовал систему анимаций на Canvas. В статье поделюсь опытом создания частиц и физики на чистом JS, а также бегло разберу встроенные инструменты браузера для таких задач. Мы будем делать схематичную анимацию фейерверков и конфетти по нажатию на кнопку при помощи JS. Изученные принципы универсальны для любого ЯП. Нам понадобится немного знаний ООП, тригонометрии, физики и совсем чуть-чуть геометрии. Вот что получится в итоге:

https://habr.com/ru/articles/1001462/

#javascript #canvas #HTML5_Canvas #Система_частиц #Чистый_JS #ООП #физика_в_Web #анимация_в_Web

[Перевод] Энди Хант «Говори, а не спрашивай»

В своем кратком тексте 1998 года Энди Хант, отталкиваясь от закона Деметры и принципа разделения команд и запросов, просто и понятно излагает один из важных принципов объектно-ориентированного проектирования — «говори, а не спрашивай». Этот принцип учит делегировать объектам ответственность за их данные, что позволяет создавать слабосвязанные и устойчивые к изменениям системы.

https://habr.com/ru/articles/990790/

#история_it #ооп #проектирование_и_рефакторинг #java #eiffel

[Перевод] Стив Фриман, Нэт Прайс, Тим Маккиннон, Джо Уорнc «Мокируем роли, а не объекты»

Продолжаем серию публикаций, посвященных истокам лондонской школы тестирования. В статье "Мокируем роли, а не объекты" (2004) авторы совершают ключевой концептуальный переход. Они переосмысливают мок-объекты: из инструмента для изоляции тестов они становятся инструментом для выявления интерфейсов, проектирования взаимодействий между объектами и создания целостной архитектуры системы.

https://habr.com/ru/articles/988518/

#история_it #ооп #тестирование #java #mock #tdd

[Перевод] Стив Фриман, Нэт Прайс, Тим Маккиннон, Джо Уорнc «Мокируем роли, а не объекты»

Продолжаем серию публикаций, посвященных истокам лондонской школы тестирования. В статье "Мокируем роли, а не объекты" (2004) авторы совершают ключевой концептуальный переход. Они переосмысливают мок-объекты: из инструмента для изоляции тестов они становятся инструментом для выявления интерфейсов, проектирования взаимодействий между объектами и создания целостной архитектуры системы.

https://habr.com/ru/articles/988518/

#история_it #ооп #тестирование #java #mock #tdd

[Перевод] Стив Фриман, Нэт Прайс, Тим Маккиннон, Джо Уорнc «Мокируем роли, а не объекты»

Продолжаем серию публикаций, посвященных истокам лондонской школы тестирования. В статье "Мокируем роли, а не объекты" (2004) авторы совершают ключевой концептуальный переход. Они переосмысливают мок-объекты: из инструмента для изоляции тестов они становятся инструментом для выявления интерфейсов, проектирования взаимодействий между объектами и создания целостной архитектуры системы.

https://habr.com/ru/articles/988518/

#история_it #ооп #тестирование #java #mock #tdd

Как мы автоматизировали преподавание ООП и обнаружили, что ChatGPT — это не враг, а союзник (с оговорками)

Как мы автоматизировали курс ООП для 360 студентов и открыли неожиданные закономерности. Почему посещаемость важна, а умеренное использование LLM даёт наивысшие баллы. История системы Frieren, которая спасла 7 преподавателей от рутины и показала, как студенты на самом деле учатся в эпоху AI.

https://habr.com/ru/companies/itmai/articles/981114/

#ооп #маи #n8n #python #обучение_программированию #автоматизация

[Перевод] Алан Кей об отправке сообщений

В октябре 1998 года, разочарованный упрощенным пониманием ООП, Алан Кей написал сообществу Squeak знаковое письмо. В нем он напомнил, что главная идея Smalltalk, о которой все забыли, — это не классы, а отправка сообщений. Это письмо стало манифестом, отделяющим оригинальную философию объектов от ее популярной интерпретации. Публикуем перевод этого короткого, но исторически важного документа.

https://habr.com/ru/articles/982960/

#ооп #история_it #smalltalk #программирование

Мало кто знает, но в Python есть switch/case: Гид по структурному сопоставлению (match/case) не только для версии 3.10+

Разбираем мощь match/case в Python: от базового синтаксиса до распаковки JSON и эмуляции в старых версиях.

https://habr.com/ru/articles/981130/

#Python #switchcase #ООП

Эволюция плеера RUTUBE: от монолита к гибким модулям

Принимая архитектурные решения, часто так или иначе приходится идти на компромисс: между качеством и скоростью разработки, сложностью реализации и удобством поддержки, быстротой решения бизнес-задачи и гибкостью. Со временем небольшие уступки накапливаются и проект покрывается легаси. Даже если исправно разгребать техдолг, то в любом случае на достаточно длинной дистанции решения и технологии устареют, и станет невозможно обойтись «генеральной уборкой» — потребуется смена архитектуры. В статье расскажу, как мы столкнулись с неизбежной необходимостью переделки веб-плеера RUTUBE — сервиса, который существует с 2006 года, пережил несколько смен команд и парадигм разработки и при этом достаточно большой и высоконагруженный, чтобы нельзя было «просто так взять и всё переписать».

https://habr.com/ru/companies/habr_rutube/articles/977276/

#rutube #mobx #ооп #видео #hls #ui #dependency_injection

Эволюция плеера RUTUBE: от монолита к гибким модулям

Принимая архитектурные решения, часто так или иначе приходится идти на компромисс: между качеством и скоростью разработки, сложностью реализации и удобством поддержки, быстротой решения бизнес-задачи и гибкостью. Со временем небольшие уступки накапливаются и проект покрывается легаси. Даже если исправно разгребать техдолг, то в любом случае на достаточно длинной дистанции решения и технологии устареют, и станет невозможно обойтись «генеральной уборкой» — потребуется смена архитектуры. В статье расскажу, как мы столкнулись с неизбежной необходимостью переделки веб-плеера RUTUBE — сервиса, который существует с 2006 года, пережил несколько смен команд и парадигм разработки и при этом достаточно большой и высоконагруженный, чтобы нельзя было «просто так взять и всё переписать».

https://habr.com/ru/companies/habr_rutube/articles/977276/

#rutube #mobx #ооп #видео #hls #ui #dependency_injection

Эволюция плеера RUTUBE: от монолита к гибким модулям

Принимая архитектурные решения, часто так или иначе приходится идти на компромисс: между качеством и скоростью разработки, сложностью реализации и удобством поддержки, быстротой решения бизнес-задачи и гибкостью. Со временем небольшие уступки накапливаются и проект покрывается легаси. Даже если исправно разгребать техдолг, то в любом случае на достаточно длинной дистанции решения и технологии устареют, и станет невозможно обойтись «генеральной уборкой» — потребуется смена архитектуры. В статье расскажу, как мы столкнулись с неизбежной необходимостью переделки веб-плеера RUTUBE — сервиса, который существует с 2006 года, пережил несколько смен команд и парадигм разработки и при этом достаточно большой и высоконагруженный, чтобы нельзя было «просто так взять и всё переписать».

https://habr.com/ru/companies/habr_rutube/articles/977276/

#rutube #mobx #ооп #видео #hls #ui #dependency_injection