ООП *

Просто закройте эту главу, если вы не научились с юмором, здоровым сарказмом и самокритикой смотреть на абсурд происходящего. Её текст точно соответствует исторической фактуре, но оскорбит «чувства верующих».

В народе говорят: «носится как дурак с фантиком». Многие технические или кажущиеся такими решения, казалось бы, даже в компьютерной сфере не имели научной подоплёки. Чтоб не ошибиться в выборе технологии, нужно было учесть исторический и политический факторы.

Ниже истории о провальных идеях, стоивших жизни и карьеры многим разработчикам. Без знания их, прошлое будет настигать снова и снова.

Эта глава о бездумном следовании догмам, а не о том, что та или иная вещь плоха (хотя и об этом – тоже).

WireMock.Net умеет мокать gRPC. Но для этого он заставляет разработчика таскать .proto файлы и поддерживать лишнюю конфигурацию. Я контрибьютил в проект несколько месяцев, разобрался в кишках и написал своё расширение WireMock.Grpc.Protobuf

Пакет предлагает gRPC моки через типизированные контракты Google.Protobuf. Получилось короче, надёжнее и заметно удобнее. В статье покажу, почему мой способ удобнее стандартного, как всё устроено под капотом и зачем вашему проекту пакет WireMock.Grpc.Protobuf

Кстати, подобные инженерные разборы, open-source и внутренности .NET я регулярно публикую в Telegram-канале StepOne. Если статья зайдёт — заглядывайте.

Речь о процедурно‑параметрическом программировании, о котором почти никто не пишет. Я реализовал одну и ту же задачу в ООП и в этой парадигме и сравнил их численно. Одна из метрик разошлась в 6 раз.

Есть вопросы, которые кажутся принадлежащими разным мирам. «Должен ли квадрат наследовать прямоугольнику?» — вопрос инженера за обедом. «Реальны ли универсалии или существуют лишь единичные вещи?» — вопрос, из-за которого в средневековых университетах ломали карьеры. Тезис статьи в том, что это один и тот же вопрос, и что программист, выбирая между интерфейсом и абстрактным классом, между наследованием и композицией, между актором и разделяемой памятью, совершает — обычно не подозревая — акт метафизического выбора, за которым стоят две с половиной тысячи лет спора.

Идеи аспектно-ориентированного программирования до сих пор широко используются в современных языках и фреймворках — достаточно вспомнить их роль в экосистеме Spring. Однако при всей практической востребованности сама парадигма остается как будто в тени. Чтобы немного это исправить, мы публикуем перевод текста Грегора Кизалеса и его коллег из Xerox PARC — первого полноценного манифеста АОП, представленного на конференции ECOOP ’97 и заложившего основы для дальнейших исследований в этой области.

Всем привет!

Меня зовут Дмитрий Бутенко, я эксперт-разработчик банка Уралсиб.

Всё началось с рабочего созвона в первой половине февраля, на котором упомянули возможность применять модели ИИ прямо внутри инфраструктуры банка. Поначалу речь шла о работе через JetBrains AI Assistant — точечные запросы, ревью, вопросы по проекту. Вопросов, кстати, было много. Но довольно скоро случился переход на OpenCode, и это открыло принципиально другой уровень: не отдельные запросы к модели, а полноценные агенты, которые сами читают файлы, вносят изменения, итерируются по результату.

О том, какими были эти вопросы и задачи, и о том, что из этого вышло — речь пойдёт ниже.

Каждый, кто хоть немного работал с объектно-ориентированными языками, наверняка сталкивался с принципом подстановки Лисков. При этом мало кто знает, откуда этот принцип взялся и в каком контексте Лисков его формулировала. Мы перевели ее доклад, прозвучавший на OOPSLA'87, чтобы дать каждому возможность обратиться к первоисточнику. Прочитав этот текст, вы увидите, насколько сложным и неочевидным было отношение Лисков к наследованию и как она связывала его с идеями абстракции, инкапсуляции и полиморфизма.

Инкапсуляцию и наследование часто преподносят как две неотъемлемые опоры объектно-ориентированного программирования, однако на деле между ними существует глубокое внутреннее противоречие. Статья Алана Снайдера, опубликованная по итогам его выступления на OOPSLA’86, стала одним из первых программных текстов, вскрывших эту проблему на уровне языковых конструкций, и показала, как неаккуратно реализованное наследование способно разрушить инкапсуляцию, а вместе с ней — преимущества модульного проектирования. Работа во многом предопределила дальнейшие дискуссии о хрупком базовом классе, роли контрактов между классами и их потомками и о том, каким должен быть внешний интерфейс класса в условиях наследования.

В своей программной статье, опубликованной по итогам выступления на OOPSLA '89, Ребекка Вирфс-Брок и Брайан Уилкерсон излагают основы проектирования через ответственность. Отталкиваясь от модели клиент/сервер и идеи контракта, авторы показывают, что акцент на поведении и ответственностях, а не на структуре данных, позволяет максимально раскрыть потенциал инкапсуляции, делая систему более гибкой и устойчивой к изменениям.

Всем привет! Я Дмитрий Милов, Python-разработчик компании МУЛЬТИФАКТОР в команде продукта MULTIDIRECTORY, мы разрабатываем собственную службу каталогов.

Как это обычно бывает в процессе развития продукта, код постепенно перестает помещаться в привычные рамки. Мы начали обсуждать, какое архитектурное решение лучше подходит нашей системе. Спор об определениях затянулся: у каждого были аргументы, почему одно решение лучше другого.

Почему продолжается путаница в концепциях, которые давно описаны и формализованы?

Открываешь чужой код на Python, а там — Java. Абстрактные базовые классы в местах, где хватило бы простой функции, фабрики фабрик и нагромождение паттернов, усложняющих чтение бизнес-логики. Знакомая картина?

Многие разработчики механически переносят архитектурные привычки из строго типизированных языков в Python, создавая переусложненный неидиоматичный код. В этой статье мы возьмем классические правила SOLID и переведем их на язык динамической типизации (Pythonic way). Разберем на реальных примерах, где принципы спасают проект, а где слепое следование им скатывается в карго-культ.

Привет, Хаброжители! Практическое руководство по подготовке к OOD-собеседованиям в ведущих IT-компаниях. Книга предлагает четкую 4-этапную схему проектирования, глубокий разбор основ ООП и SOLID, а также 14 готовых к реализации систем (парковка, кинотеатр, банкомат, ресторан, лифты и др.). Каждый кейс сопровождается сбором требований, UML-диаграммами, рабочим кодом и проработкой граничных случаев. Дополнительно — паттерны проектирования и советы по коммуникации. Идеальный инструмент, чтобы перейти от теории к уверенной практике.

Привет, Хабр!

В этой статье я расскажу об эволюции моего проекта — GroupModerBot, бота для модерации Telegram‑групп. Я покажу, как проект прошел путь от первой версии «всё в одном файле» до продуманной архитектуры с ООП, in‑memory кэшированием, безопасным выполнением команд и нестандартными алгоритмами наказаний пользователей.

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

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

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

Начнём с того, что в обсуждениях объектного программирования бытуют несколько популярных мнений

Март выдался… немного тише, чем февраль.
Без громких релизов уровня Flutter 3.x — но это не значит, что было скучно 😉

Наоборот — месяц получился про практику, реальные кейсы и прокачку навыков 💪
А ещё… несмотря ни на что — мы продолжаем работать.

Да, даже несмотря на блокировки Telegram —
❌ мы никуда не уходим
❌ в MAX не переезжаем
✅ и продолжаем делать лучший Flutter-контент для вас

👉 Подписка на канал сейчас — это реальная поддержка проекта ❤️
https://t.me/flutterpulse

Привет, хабр! Решил поделиться с миром своим проектом, который делался в свободное время и был мне полезен на моей текущей работе. Ссылка на гитхаб https://github.com/simplepersonru/SimpleOntoDoc

Проект - генератор статического сайта документации для онтологической модели данных
Онтологическая модель данных — это способ формального описания предметной области, в основе которого лежат три главные вещи:

1. Классы (типы объектов, «сущности»).
2. Атрибуты (свойства этих классов).
3. Связи (отношения между классами).

Под катом:

+ Мотивация (зачем мне это нужно)
+ Как это выглядит (с опубликованным примером)
+ Как можно применить (зачем Вам это нужно)

AI дисклеймер - при написании статьи активно использовалась нейросеть головного мозга, будьте осторожны

Доброго здоровья!

Предполагается, что статья будет интересна тем, кто любит четкие контракты в своих проектах, строгость и чистоту в инкапсуляции, новые подходы в ООП. А также тем, кто уважает функциональное программирование.

Эти темы и затрагиваются в предлагаемом «Elvis-модификаторе доступа», реализованным через Roslyn Analyzer. Все исходники и nuget пакеты прилагаются.

Как я писал в предыдущей статье при разработке прототипа системы взаимодействующих движков первыми движками оказались тактовые генераторы, задающие время и синхронизацию коллектива движков.

Остальные рабочие движки можно было бы стандартно реализовать с помощью нескольких специфических серверов движков, но мне захотелось сделать всё по правилам ООП и испытать выразительную мощь языка Elixir. Т. е. дальнейшую разработку предполагается провести в рамках парадигмы ООП, расширяя модуль «класса» тактовых генераторов.