ООП *

Виртуальная СУБД. Язык определения данных (DDL).

Эта статья является продолжением серии статей посвященной новой системе разработки клиентских приложений KISS Virtual XML RDBMS.

Виртуальная СУБД - это чисто объектная система управления реляционной XML базой данных. Язык определения данными представлен в виртуальной СУБД базовым классом tblschema (схема виртуальной таблицы). Этот класс предназначен для объектного представления словарей (метаданных) различных физических СУБД. Одной из главных целей создания виртуальной СУБД было обеспечение ее независимости от конкретных физических СУБД, поэтому потребовалось создать собственный универсальный объектный инструмент для определения и корректировки стандартизированных метаданных, совместимый со всеми реляционными СУБД.

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

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

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

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.

Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.

С появлением LLM люди разделились на три лагеря: тех, кто верит в повышение КПД при помощи автодополнения и тех, кто относится к хайпу крайне скептически. Третий лагерь — это сами LLM, они же тоже что-то там про себя думают, наверное.

За долгие годы работы с кодом я привык слышать от среднего уровня разработчиков (и от тех, кто выбрал языки, которым требуется бесконечная генерация бойлерплейта): «Продуктивность программиста напрямую зависит от IDE». При том, что я всегда производил в несколько раз больше самого сложного в компании кода, используя vim с минимумом плагинов. Подсветка синтаксиса мне помогает, тут (как, впрочем, и почти везде) я с Пайком не согласен. Автодополнение — уже нет, я его иногда включаю «еще раз попробовать, вдруг это со мной что-то не так», и когда читаю курсы — но в основном мне мешают выскакивающие окошки: отвлекают, распыляют внимание, наталкивают на ложный путь.

TL;DR: Нет. Хорошо спроектированный язык в развитии не нуждается.

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

Более того, ниже я постараюсь уложиться в нескольких абзацев, чтобы рассказать, какие требования лично я предъявляю языку программирования в 2025 году, и почему этому «идеалу» просто некуда «развиваться».

Логирование является одним из ключевых и важнейших элементов разработки и эксплуатации приложений. Умение правильно вести журнал логов — ключ к эффективной отладке и мониторингу приложений. Оно дает ценную информацию всей цепочке заинтересованных лиц: от разработчиков и системных администраторов до руководителей бизнеса.

В статье рассмотрен де-факто стандарт логирования — модуль logging в Python. Я дам общие рекомендации по его настройке и опишу практики применения модуля, подходящие для большинства случаев.

Все современные средства разработки — практически без исключения — наделены двумя родовыми травмами. Они не дают доступа к чуть более низкому софтверному уровню (синтаксическому дереву) без помощи сторонних хаков и ориентированы на синхронное исполнение.

Прежде, чем продолжить, я сразу оговорюсь: я не имею в виду узкоспециализированные задачи, типа написания драйверов, программирования контроллеров и прочей околожелезной разработки; там другие правила. Я говорю про мир приложений: от инди-игр до энтерпрайза. Языки высокого уровня, на которых сегодня ведется более (оценка навскидку) 98% всей разработки продуктов для конечного пользователя, лишены примитивов представления AST и параллельного (не путать с асинхронным) исполнения.

Привет! Мы — команда Яндекс Практикума и эксперты курса «Python-разработчик». В этой статье собрали полезные ресурсы, которые помогут освоить принципы объектно-ориентированного программирования (ООП) и научиться применять их на практике.

Если на Силикатной улице (это в Мытищах) остановить тысячу случайных прохожих и спросить их, на каких трёх слонах покоится ООП, каждый второй назовёт инкапсуляцию. В коридорах МИФИ, или на собеседовании в Яндексе — процент будет даже выше. Даже LLM способна на шести пальцах объяснить, почему.

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

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

У меня появилась необходимость отделить проект от фреймворка. Благо кода фреймворка в проекте было не так много, но избавиться от него тоже нужно.
Поэтому было принято решение переписать функционал который он покрывал.
Одной из используемых функций фреймворка было - построение пространства имен.

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

Удачно получилось что тема пересекается с моей статьей. Может если это будет серия статьей с пометкой Клиентский код, то мне получится лучше донести что же всё-таки это за код такой.

Книги делятся на две категории: fiction и non-fiction. Технические книги — внезапно — не исключение, и поддаются точно такой же классификации. Между учебником по научной дисциплине, начинающегося с аксиоматики и продолжающегося доказательствами теорем, — и практически любой современной литературой по «Computer Science» — лежит пропасть. Что происходит, когда люди долгое время оказываются рабами одной-единственной книги (с продолжениями), нам хорошо известно из истории. Возникает религия.

99% процентов литературы по ООП — это талмуд. Вероятность того, что вам подойдет «паттерн» — примерно 50%. Как встретить динозавра на Невском. Знание паттернов полезно в той же степени, что и теология, — и примерно тем же по специальности людям. Всегда полезно уметь отличать по запаху Пана от простого фавна, но практических применений такой эрудиции — не существует.

Зайду с козырей: КДПВ этой заметки имеет прямое отношение к тексту.

Если вы сфокусируете взгляд на синей рамке, вы увидите растопырившего лапы Амбидиректуса с вытянутой шеей и маленькой головой, развернутой влево. Перефокусируясь на красную рамку, вы познакомитесь с его приготовившимся нырнуть в стену справа Alter Ego, с плотно ввинченной в шею головой и замершими во взмахе назад передними конечностями.

Я показал вам этого Амбидиректуса для того, чтобы проиллюстрировать основную мысль этого текста: споры о превосходстве той или иной парадигмы над остальными — не имеют никакого смысла и всегда являются религиозной войной остроконечников против тупоконечников.

Данная статья является продолжением серии статей посвященных Системе разработки клиентских приложений (KISS Virtual XML DBCS). В этой статье рассматривается синтаксис языка программирования ULCA (Universal Language for Client Application) , используемого этой Системой.

ULCA (Universal Language for Client Application) - Новый объектный интерпретируемый язык программирования, предназначенный для разработки клиентских desktop и web приложений. Данная статья является продолжением серии статей посвященных Системе разработки клиентских приложений (KISS Virtual XML DBCS). В этой статье рассматривается объектная модель, используемая языком программирования ULCA .

Основы

Привет, дорогой друг!

Сегодня я тебе объясню принципы SOLID максимально понятным способом.

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

Представь себе, что ты решил заняться бизнесом.

Первым делом ты организуешь небольшую торговую компанию. Ты только начинаешь свой путь в бизнесе, и поэтому всё делаешь сам. И закупаешь товар, и развозишь его по точкам, и ведёшь учёт, и ремонтируешь грузовую газель.

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

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

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

Но ты стоишь на страже интересов бизнеса! Железной рукой ты пресекаешь безобразия и вводишь жёсткий принцип – каждый сотрудник отвечает только за своё поле деятельности, у каждого своя ответственность, и никто в чужой огород лазать не смей. Закупщик – только закупает. Продажник – только продаёт. Каждый сотрудник должен иметь только одну зону ответственности.

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

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

Я честно, не знаю как в других профессиях, но в программировании, как мне кажется, собеседования — это чистая лотерея. Мое видение этого возможно подтверждает рынок труда — накрути себе опыта побольше, примени нейросеть, расскажи красиво о себе и вот работа (зарплата) мечты уже твоя. Следствием этого — по 300 отзывов на вакансию. Но, к слову, вакансии эти висят месяцами. Ты просто попадаешь в огромную кучу кандидатов, которых работодатель хочет отсеять и выбрать лучшего из вас. По каким критериям (по всем кроме трудовой книжки) вас будут сортировать одному Нео известно. Так‑же имел личный опыт, когда я отвечал полностью на все вопросы в течение часа. Получив оценку своим знаниям на 5+, заветную работу (зарплату) мечты я так и не получил.

Как-то мне выпало написать небольшой микросервис, код которого практически полностью состоял их одних реализаций паттернов "Банды четырех". В этой статье я хочу рассказать о том, как последовательное решение поставленной задачи приводило к использованию все новых паттернов, и как эти паттерны взаимодействовали между собой.

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

Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных приложений (да и Android‑приложений тоже). Однако это семейство архитектур в контексте прикладной разработки зачастую не даёт никаких преимуществ, а только привносит лишние церемонии и тем самым замедляет её.

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

Но перед тем как перейти к Чистой архитектуре, сначала надо разобрать принцип инверсии зависимостей (Dependency Inversion Principle, DIP).

Привет! Хотелось бы поделиться с вами своей мудростью примером структуры, которая подойдёт практически для любых сервисов вне зависимости от того, гоняете ли вы JSON-ы в микросервисах или разрабатываете монолитное решение со сложной бизнес-логикой.