ООП *

Всем привет!

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

Всё началось с рабочего созвона в первой половине февраля, на котором упомянули возможность применять модели ИИ прямо внутри инфраструктуры банка. Поначалу речь шла о работе через 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. Т. е. дальнейшую разработку предполагается провести в рамках парадигмы ООП, расширяя модуль «класса» тактовых генераторов.

def get_features_all(y, sr):
"""
Получаем различные параметры аудио которые в сумме дадут уникальный набор признаков
"""
# Частота цветности
chst = librosa.feature.chroma_stft(y=y, sr=sr)
# Среднеквадратичные колебания (энергия сигнала)
rmse = librosa.feature.rms(y=y)
# Пересечения нуля (частота смены знака сигнала)
zcr = librosa.feature.zero_crossing_rate(y)
# Центр масс звука (спектральный центр)
spe_c = librosa.feature.spectral_centroid(y=y, sr=sr)
# Ширина полосы частот
spe_b = librosa.feature.spectral_bandwidth(y=y, sr=sr)
# Спектральный спад частоты
rol = librosa.feature.spectral_rolloff(y=y, sr=sr)
# Значимые для обработки частоты (MFCC)
mfcc = librosa.feature.mfcc(y=y, sr=SR, n_mfcc=50,
n_mels=50, hop_length=1024)
return chst, rmse, zcr, spe_c, spe_b, rol, mfcc

В данной статье хочу поделиться своим опытом по абстрактным классам. Думаю  это будет полезно как разработчикам, только начинающим свой путь, так и уже имеющим опыт. 

В материале можно посмотреть, как изящно связать свойства  и абстрактные классы с реализацией принципа DRY .

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

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

Абстрактные методы - методы с декоратором @abstractmethod, которые обязаны быть реализованы в дочерних классах.

Абстрактный класс может содержать как обычные, так и абстрактные методы.

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

Вы освоили переменные, разобрались с циклами и научились писать функции. Ваши скрипты бодро парсят сайты, перекладывают файлы или считают статистику. Жизнь кажется прекрасной, а Python — лучшим языком в мире.

Но однажды проект начинает расти.

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

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

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