ООП *

Я переписывался с товарищем на тему архитектуры и сформировал более цельное понимание построения ООП-кода :)

Чуть-чуть обо мне: в разработке 12+ лет, сделал 50+ различных приложений и ещё немножко игр, это только для бизнеса, плюс еще мои личные эксперименты и petproject-ы.

Делая все эти приложения я пришел к тому что есть разные подходы к проектированию\моделированию систем, в частности с помощью ООП-кода:

(Условно назову эти типы в игровой терминологии так как разговор был с человеком из геймдева и игры мне тоже близки, кстати, я и программировать то начал чтобы делать игры 😁, итак вот эти подходы: )

1. "Action" - когда ты описываешь объекты как будто смотришь на описываемую систему изнутри (вид из глаз), фокус на взаимодействие объектов между собой в моменте, моделируются в первую очередь сущности и упускаются процессы.

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

3. "God Mode" - когда ты делаешь все что душе угодно (читай как и то и другое, "Action" и "Strategy" в одном флаконе)

И так же я пришел к тому что есть несколько слоев моделирования\проектирования:

(как сказали бы в Теории Систем - есть надсистема, есть система и есть подсистема, а Шрек описал бы это как слои лука, а Осел рассказал бы что это напоминает слоёный торт 😁)

1. Уровень реальности в которой есть человек пользователь, используемый девайс (десктоп, ноутбук, смартфон, и т.п.), сервер с бэкендом; правила их взаимодействия (интерфейсы, протоколы, договоренности); и процессы в которых это взаимодействие происходит (циклы, цепочки событий, потоки данных)

2. Уровень приложения в котором есть сущности бизнес-логики(игровой логики), например Hero, Enemy, Obstacle, Menu, Map, Score; правила их взаимодействия; и процессы в которых происходит взаимодействие

3. Уровень инструментов в котором есть сущности языка программирования такие как примитивы(Int, Long, String, Bool), структуры данных, основные компоненты игрового движка(операционной системы); правила их взаимодействия; и процессы в которых происходит это взаимодействие

(правила взаимодействия могут быть явными и неявными, когда мы описываем объекты классами с методами и функциями, по сути мы уже задаем правила и зависимости объектов, но иногда для удобства мы можем вынести эти правила в отдельные абстракции и интерфейсы, чтобы задать рамки, границы использования однородных классов и абстрагироваться от конкретной реализации, и потом удобно переиспользовать повторяющиеся действия в процессе выполнения)

На каждом слое может использоваться как ООП подход так и ФП, так и нечто смешанное что добавляет удобства.

К чему это все? Наш разговор начался с того что я вбросил мнение что самая чистая архитектура обычно это чистейший ООП-код, и удобство архитектуры зависит как раз от навыка моделирования систем этим ООП-кодом.

Такие дела :)

Я по прежнему считаю что ООП рулит! 😁

А что думаешь ты про ООП, архитектуру и чистый код?

Делись своим опытом в комментариях, или нет..

Я исследовал тему связности и связанности в построении кода и вот к чему пришел:

Не существует плохих\хороших\идеальных связности и связанности кода.

Мне кажется проблема и решение глубже - сколько людей столько и вариантов осмысления и построения "модели", столько вариантов же coupling & cohesion. У каждого что-то свое.

Строить приложение от архитектуры - такое себе. Архитектура для приложения, а не приложение для архитектуры. Тогда архитектура будет основана на реальных задачах а не на поиске идеала.

Самая лучшая архитектура как по мне это когда ты пишешь в ООП стиле, и вот тут как ты умеешь моделировать что-то, такая архитектура у тебя и получится, со всей связностью и связанностью.

Ведь суть всего этого моделирования чтобы "на понятном" объяснить железу что и когда нужно сделать.

Т.е. решение кроется в здравом смысле - описываешь приложение плюс-минус понятными человеку структурами и нужная связность и связанность образуются сами собой как следствие.

Ну и когда я говорю ООП, это не значит что я буду писать абстракцию на каждый чих, влоть до Int, Long и т.п., нет, это значит что я начну с самых больших MyApp { UserClient, ServerClient, DeviceClient } и законтачу их между собой логикой приложения, а там дальше буду создавать абстракции по необходимости, если будет удобно и полезно что-то добавить и переиспользовать то я добавлю и переиспользую (вот кстати хороший критерий - моделировать сущность когда надо что-то передавать между главными абсракциями(надсистемами)).

ООП рулит :)

P.S. И не надо стремиться к идеалу, иначе тут можно скатиться в подмену задач, и начать делать не данное конкретное приложение, а предложенный кем-то идеал архитектуры.

Полиморфизм и наследование

Каждый раз, когда я слышу от кого-то описание или определение полиморфизма, там присутствует слово "наследование".

> Объясните что такое полиморфизм? Ну это когда базовый класс и наследники...

Давайте по порядку. Полиморфизмов вообще существует больше чем один. Но, все таки, когда речь идет про массовое программирование (простите функциональщики), по умолчанию говорят о полиморфизме подтипов (subtyping). Упрощенно, в этом полиморфизме мы заменяем иф на общий метод для разных типов объекта. Таким образом сам объект (его тип) определяет реальное поведение, а вызывающий код про это не знает, он просто дергает метод (или методы):

function doSomething(logger) {
  // Где-то снаружи выбирается конкретный логгер
  // Разные логгеры могут работать сильно по разному
  logger.info('hey');
}

Что мы тут получили? Возможность менять поведение конфигурированием приложения (меняем тип объекта во время настройки), а не тем, что ходим по ифам где выбирается конкретная реализация и меняем там код.

Нужно ли для этого наследование? Вообще не нужно и вообще не подразумевается. Типами и подтипами во всех определениях являются интерфейсы или их аналоги, но не классы. Более того, в динамических языках у вас в принципе сами по себе классы могут быть никак не связаны, главное чтобы в них был реализован один и тот же полиморфный метод.

Кстати, для реализации полиморфизма подтипов классы тоже не нужны. Есть немало языков где он есть, но там нет ни классов ни ооп в привычном варианте.

Больше про разработку в моем телеграм-канале Организованное программирование

Мемо: в ожидании Python 3.14

Финальный релиз Python 3.14 запланирован на 7 октября 2025. Уже вышел RC2 (14 августа), а финальный кандидат RC3 ожидается 16 сентября.
Этот пост — краткая шпаргалка, чтобы помнить, какие изменения стоит протестировать и чего ждать в новой версии.

1. Свободная многопоточность (Free-Threaded Python, без GIL)

Зачем нужно: наконец-то полноценный параллелизм и многопоточность на многоядерных системах без глобальной блокировки интерпретатора.

# Включение free-threaded режима при сборке
# ./configure --disable-gil
import threading

def cpu_bound_task(n):
    return sum(i*i for i in range(n))

threads = [threading.Thread(target=cpu_bound_task, args=(10**6,)) for _ in range(4)]
[t.start() for t in threads]
[t.join() for t in threads]

Free-Threaded Python теперь не будет экспериментальным и будет официально поддерживаться, но пока пока будет являться опциональным, по умолчанию остаётся GIL.

2. Отложенная оценка аннотаций типов

Зачем нужно: ускорение работы и избавление от кавычек при forward references. Появился новый модуль annotationlib для работы с аннотациями.

# from __future__ import annotations
import annotationlib

class Node:
    def __init__(self, value: int, next: Node | None = None):
        self.value = value
        self.next = next

print(annotationlib.get_annotations(Node.__init__))

Аннотации больше не обрабатываются при определении функций, классов и модулей. Они сохраняются в специальных функциях аннотирования и обрабатываются при необходимости.
Импорт from future import annotations можно удалить при поддержке Python 3.14 и новее.

3. Template-строки (t-строки)

Зачем нужно: безопасное форматирование строк, полезное для веба и DSL, расширение возможностей f-строк.

name = "<script>alert('xss')</script>"
age = 25

tpl = t"Hello {name}, you are {age}"
safe = tpl.format(name=escape_html(name), age=age)
print(safe)

4. Zstandard-сжатие

Зачем нужно: современный алгоритм сжатия, быстрее gzip и удобнее для больших блоков данных.

import compression.zstd

data = b"Large dataset" * 1000
compressed = compression.zstd.compress(data, level=3)
decompressed = compression.zstd.decompress(compressed)

print(f"Ratio: {len(data) / len(compressed):.2f}")

5. Удалённая отладка процессов

Зачем нужно: можно подключать отладчик к работающему приложению без перезапуска и накладных расходов.

import sys
import pdb

# Подключение отладчика к работающему процессу
sys.remote_exec("""
import pdb; pdb.set_trace()
""", target_pid=12345)

# Безопасное выполнение кода в удаленном процессе
result = sys.remote_exec("print('Debug info:', some_variable)", target_pid=12345)

6. Экспериментальный JIT-компилятор

Зачем нужно: ускорение выполнения вычислительно интенсивных задач.

# Включается флагом при запуске
# python --jit script.py

def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n-1) + fibonacci(n-2)

# JIT автоматически оптимизирует "горячие" функции
result = fibonacci(35)  # Заметно быстрее с JIT

7. REPL с подсветкой синтаксиса

Зачем нужно: удобнее писать и отлаживать код прямо в интерактивной оболочке.

>>> def hello(name: str) -> str:
...     return f"Hello, {name}!"
>>> hello("World")
'Hello, World!'

Что стоит попробовать?

1. Потестировать free-threaded режим на CPU-нагруженных задачах.

2. Перейти на новый синтаксис аннотаций без кавычек.

3. Проверить t-строки в веб-шаблонах и DSL.

4. Протестировать zstd для больших массивов данных.

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

Подробнее на python.org: What’s new in Python 3.14

Выводим Бугаенко на чистую воду разбирая ООП

Топ Перлов

• Любой массив байт должен уметь работать с файлами, сетью и тд.

• Программа должна не падать на ошибках, а продолжать работу с фейковыми объектами.

• Вместо падения в моменте конструирования объекта, надо падать на другом конце программы при каждом его использовании.

• Я придумал новый язык, и чтобы он не так сильно тормозил, надо встроить GC в CPU.

Упомянутые ссылки

• Парадигмы диспетчеризации (включая ООП)

• Виды объектных декомпозиций (включая MVC)

Копилка благодарностей

Что такое архитектура ПО и почему она не про красивые диаграммы

🏗️ Архитектура программного обеспечения — это не просто модное слово для повышения ставки на собеседовании. Это фундамент, на котором строится вся система.

Что это такое на самом деле?
Архитектура ПО — это структура компонентов системы, их взаимосвязи, взаимодействия с внешней средой и принципы разработки. Звучит скучно? А вот и нет! Это как план города: без него у вас получится не Москва, а какая-то деревня Гадюкино с кривыми улочками.

Зачем это нужно?

• Снижает сложность системы через декомпозицию

• Определяет рамки развития (чтобы не росло как раковая опухоль)

• Помогает команде говорить на одном языке

• Экономит нервы и деньги в долгосрочной перспективе

Под капотом архитектура отвечает за:
✅ Разбиение системы на модули (как LEGO, только для взрослых)
✅ Способы взаимодействия компонентов (REST, RPC, события)
✅ Распределение ответственности между модулями
✅ Выбор технологического стека

Простой пример:
Представьте интернет-магазин. Без архитектуры у вас будет один гигантский файл на 50,000 строк, где корзина покупок живёт рядом с логикой оплаты, а пользовательские данные перемешаны с каталогом товаров. С архитектурой — отдельные модули: UserService, CatalogService, PaymentService, каждый со своей зоной ответственности.

🔧 Давайте разберём базовые понятия архитектуры, без которых никуда. Это как алфавит — скучно учить, но без него читать не получится.

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

Пример компонентов:

• Authentication Service (следит, чтобы чужие не лезли)

• Notification Service (шлёт уведомления)

• Data Storage (хранит данные, очевидно)

Интерфейс — способ взаимодействия между компонентами. Это как протокол дипломатии: все знают правила игры, никто не лезет с кулаками.

Типы интерфейсов:

• REST API (классика жанра)

• Message Queue (асинхронные сообщения)

• RPC (удалённые вызовы)

• Database API (работа с данными)

Связи  — физические или логические каналы передачи данных между компонентами. Это как дороги в городе: определяют, кто с кем может общаться и как.

Примеры связей:

• HTTP-соединения (веб-траффик)

• TCP/UDP сокеты (низкоуровневая связь)

• Message Brokers (Apache Kafka, RabbitMQ)

• Database connections (пул соединений с БД)

Модуль — логическая группировка компонентов по функциональности. Это как департаменты в компании: HR, IT, Бухгалтерия.

Примеры модулей:

• User Management Module (всё что касается пользователей)

• Payment Processing Module (платежи и транзакции)

• Analytics Module (метрики и отчёты)

Сервис — автономная единица бизнес-логики с чётко определённой ответственностью. Это как мини-приложение внутри большого приложения.

Примеры сервисов:

• Order Service (управление заказами)

• Inventory Service (управление товарами)

• Billing Service (выставление счетов)

Хранилище данных — компонент, отвечающий за персистентность информации. Это как склад или архив компании.

Типы хранилищ:

• Реляционные БД (PostgreSQL, MySQL)

• NoSQL (MongoDB, Redis)

• Файловые системы (S3, локальные диски)

• Кэши (Redis, Memcached)

SLA — характеристики работы сервиса. Это контракт: "обещаю работать 99.9% времени и отвечать за 200ms".

Зачем нужны SLA:

• Понимание ожиданий от системы

• Планирование мощностей

• Определение критичности сервисов

• Основа для мониторинга

Практический пример:
Сервис авторизации должен:

• Отвечать за 100ms в 95% случаев

• Быть доступным 99.95% времени

• Выдерживать 1000 RPS

Чеклист для правильного проектирования:
✅ Каждый компонент имеет чёткую ответственность
✅ Интерфейсы документированы
✅ Связи (способы взаимодействия) определены
✅ Деление на сервисы произведено
✅ Способ хранения данных определен
✅ SLA определены и измеряемы
✅ Зависимости между компонентами минимальны

Помните: хорошая архитектура начинается с понимания базовых элементов. Без этого ваша система превратится в спагетти-код корпоративного масштаба.

Из чего состоит MeyerSAN — решение для имитации ошибок в СХД

Проект MeyerSAN — это программно-аппаратный комплекс на основе сервера VEGMAN. Комплекс имитирует неисправность SAS HDD и SSD и позволяет автоматически тестировать реакцию системы хранения данных на ошибки. Решение необходимо для тестирования и валидации работы подсистем, которые находятся в составе СХД и определяют проблемные диски. 

Как это работает: 

1. Мы подключаем сервер к системе хранения данных. 

2. С помощью ПО и драйверов заставляем СХД видеть сервер как диск или несколько дисков.

3. Вносим отклонения в поведение диска. Например, имитируем ситуацию, когда пользователь записал данные в диск, а прочитать их не смог.

Задача MeyerSAN — эмулировать проблемы с дисками: задержки, ошибки, порчу данных и метаданных.

Архитектура MeyerSAN состоит из трех больших блоков: 

1. REST, так называемый MRSNMGMT. Позволяет конфигурировать систему в соответствии с пожеланиями.

2. MRSNLib. Cодержит бизнес-логику приложения: обработку и модификацию команд.

3. Драйверы низкого уровня. Они предоставляют нам механизмы транспорта и позволяют соответствовать всем протоколам.

Средний компонент, MRSNLib, команда разработчиков написала на современном С++ 23. Как именно инженерам удалось интегрировать новейший стандарт, а также паттерны объектно-ориентированного программирования в проект MeyerSAN, рассказывает один из создателей проекта Константин Крюков в новой статье.

Я в прошлом разработчик. Поработал во многих ведущих ИТ-компаниях России. После того, как был разработчиком, работал системным аналитиком, продуктовым менедежром. Лет 12-15 назад начал увлекаться вопросами обучения детей математике. Писал даже года 3 назад на Хабре статью о том, как это мое хобби превратилось в профессию. Теперь это еще и область научных интересов: поступил в аспирантуру на мехмат МГУ на кафедру методики преподавания математики.

В нашем коллективе на мехмате существенная часть внимания сейчас прикована к явленим глубокого структурного изменения взглядов школьника на математику (например, осознание, что от числа можно перейти к переменной, или понимание, что уравнения и неравенства - это одно и то же, с точки зрения логики). У меня на этот счет есть своя теория, которую я частично заимствовал у своего научного руководителя и развил. Теория заключается в том, что задача начальной школы и первой части средней - это осваивать алгоритмы решения различных задач. Т.е. нужно уметь обосновывать каждый шаг алгоритма, но не обязательно уметь находить следующий шаг (достаточно помнить последовательность шагов). К середине средней школы алгоритмов накапливается критическая масса, и школьнику с организацией знаний на основании алгоритмов становится тяжело. Алгоритмы все больше и больше ветвятся, изменяют область своего применения и множатся. И в какой-то момент алгоритмы начинают рваться на шаги, а организация знаний начинает смещаться от алгоритмов к отношениям математических сущностей. Отношения - более оптимальная структура организации знаний. Она отлично работает там, где есть постоянные измнения структуры. Также она оптимальна для организации мышления исследователя. А очень часто дети в началке пропускают обоснование шагов алгоритма и, естественно, имеют проблемы с расчленением алгоритмов на части и формированием математических отношений. И, как следствие, им остается только все продолжать зубрить. Вот пост в моем тг-канале о том, как это прогрессирующее заболевание тянется и меняет представление об обучении.

Пример. Можно воспринимать примеры "2 + 3 = 5", "2 = 5 - 3" и "3 = 5 - 2" по отдельности, тогда знак равно будет знаком дейсвтия. А можно как одно отношение между числами 2, 3 и 5, например, 2 + 3 = 5. А вот тут теперь знак равно имеет смысл тождества.

Развивая теорию, которая могла бы описать такие переходы от алгоритмов к отношениям и которая могла бы быть основной для построения педагогических методик, я вдруг вспомнил, где я это все видел!!!! Функциональное программирование и ООП!!! У каждой из этих двух парадигм есть свои плюсы и минусы. Функциональная хороша для освоения, для быстрого создания чего-то небольшого, для кодирования чего-то большого, когда есть высокая степень определенности, а планируемые изменения не слишком велики. ООП - хорошо, когда планируются структурные изменения. По крайней мере, так было лет 10 назад. А структурные изменения - это именно то, что происходит при изучении математики в средней и старшей школе и далее.

VK (видео)

📦 API for Any(thing) 2

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Библиотека работает на продакшене в приложениях:
Энергия
NFC Tool
КубГТУ

Во второй части доклада практическая реализация 💡

Хабр
Medium
GitHub

El-Machine.com Apps 🤖

Теория:
Часть 1

Доклад Особенности фреймворка $mol (+ слайды) с PiterJS #72.

О фичах $mol, которых нет в других фреймворках, и о том, зачем они нужны.

Автор - Станислав Яременко. Герой Hyper Dev, Синьор $mol-разработчик.

Писал на Vue, Svelte. Пробовал и другие фреймворки. Как-то раз я загуглил "лучший ui фреймворк", и на первом месте в выдаче оказался $mol. Конечно, я не поверил и начал разбираться...

YouTube (видео)

📦 API for Any(thing) 

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Продолжаю развивать свою идею архитектуры для 100% инкасуляции, разбития на модули и тестирования всего слоя Model

Хабр
Medium
GitHub

Первая часть доклада теоретическая. В поисках API для любого (Any) объекта

Во второй части доклада практическая реализация 💡

Поделитесь мыслями:
Что думаете про декларативны подход? Описываю результат и получаю нужный объект

Часть 2

Я вот не понимаю, почему Го преподносится как  post-OOP язык, в то время как это явно пре-ООП язык, чисто императивный. Как Бейсик (который не Вижуал) или Паскаль.

И это явно не прогресс, а регресс в подходе к методологии.

Хотя, очевидно, он выигрывает у языков с управляемой средой, да. Управляемая среда (ВМ) требует слишком много ресурсов для старта и разогрева. А в микросервисах это вообще не нужно.

Реализация перераспределения целей (retarget) в играх RTS жанра

Учитывая предыдущую критику, что удобнее читать статьи, а не слушать видео, попробую вначале сделать акцент на тему, вынесенную в заголовок. Дело в том, что в статье концентрация информации больше, но широкий контекст обсуждения вопроса, остается за кадром. Поэтому для узконаправленной подачи информации собираюсь написать статью, а для более широкого понимания вопроса предлагаю ознакомится с представленным видео.

Задача выбора целей для атакующих NPC

В играх RTS жанра обязательно возникает задача, как выбрать для NPC цель. Мы хорошо знаем, когда игроки на их жаргоне говорят "заагрился", что означает, что некий юнит, обратил внимание на юнитов игрока, и будет их преследовать и атаковать. В ряде игр от заагрившегося юнита можно убежать, в других наоборот, он будет вас выслеживать "по запаху, остаткам крови", как это реализовано в JA3. Но как усложнится задача, когда агрессивных NPC в игре сотни, и у игрока аналогично их сотни, или тысячи. Можно ли раз и навсегда заагрится на какого то конкретного юнита? По какому принципу перераспределять цели между разными NPC? Все это не тривиальные задачи, но они имеют одно достаточно простое решение на базе алгоритма искусственного интеллекта, который своими корнями восходит к алгоритму градиентного спуска.

Global variable is not a field!

Глобальная переменная - это не поле для наследования ООП. Эта мысль посетила меня слишком поздно, поймите мою боль.
Я создал глобальную переменную, точнее даже глобальную переменную с локальной областью видимости (static). Эта переменная жила в методе. Я ожидал, что у каждого экземпляра класса будет свой метод (что верно) со своим экземпляром переменной (неверно).

void TClass::method(){
    static QByteArray globalVar; //will the same for all objects
}

Учите ООП, голубцы!