Как стать автором
Поиск
Написать публикацию
Обновить
17.45

ООП *

Объектно-ориентированное программирование

Сначала показывать
Порог рейтинга
Уровень сложности

Всё про Generic Math в C#

Уровень сложностиСложный
Время на прочтение21 мин
Количество просмотров12K


С момента своего релиза в C# 11 и .NET 7 Обобщённая Математика так и осталась тёмной лошадкой в глазах программистов. Разработчики не понимают и не используют эту фичу, статья же ответит на все вопросы и разложит всё по полочкам.

Рассмотрим с нуля концепцию Generic Math. Как она выглядит в C# и других языках программирования, почему вообще появилась. Также зароемся в «кишки» System.Numerics и узнаем, как применить в продакшне кровавого ынтэрпрайза.
Читать дальше →

Не складывайте медленный код в жобу

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров1.7K

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

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

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

В любой мало-мальской экосистеме обязательно будет такая штука, как «job runner». Чтобы линейный, простой как полено, код — мог иметь дело с длительными вычислениями. Нужен отчёт, а его генерация занимает полчаса? — Нет, мы не сделаем правильно, не поправим наши схемы, не озаботимся триггерами и persistent views, на это у нас нет ни времени, ни денег, мы стартап, поэтому делегируем: пусть весь неэффективный медленный код идёт в жобу!

Почему job runners — зло

ООП или не ООП — вот в чём ревью

Уровень сложностиПростой
Время на прочтение2 мин
Количество просмотров3.5K

Псевдокод, страсть и pull-request на грани добра и зла

Кто-то звал Smalltalk, кто-то бросал в нас Haskell, кто-то доставал из-под кровати подшивку статей «ECS лучше всего» — и всё это с праведной уверенностью.

Читать далее

Разбираем архитектуру. Часть 2. Чистая архитектура на примере FastAPI приложения

Уровень сложностиСредний
Время на прочтение50 мин
Количество просмотров12K

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

Функционально проект реализует систему сбора и анализа вакансий с агрегаторов вроде HeadHunter. Но гораздо важнее не то, какие задачи решает система, а то — как именно она это делает. Этот проект — прежде всего о структуре, архитектуре и принципах.

Основные используемые технологии: Python 3.13, FastAPI, Nginx, Uvicorn, PostgreSQL, Alembic, Celery, Redis, Pytest, FileBeat, LogStash, ElasticSearch, Kibana, Prometheus, Grafana, Docker, Docker Compose.

Читать далее

ООП не мертво. Вы просто пользуетесь им как молотком по клавиатуре

Уровень сложностиПростой
Время на прочтение2 мин
Количество просмотров53K

После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.

Читать далее

Некоторые приёмы ООП в golang

Уровень сложностиПростой
Время на прочтение8 мин
Количество просмотров5.2K

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

## Парадигма и инструменты языка

Я несколько раз встречал мнение, что го не ООП-язык. И поэтому прежде всего договоримся о том, что такое ООП.

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

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

Читать далее

ООП — это скам

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров63K

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

После прочтения большинства этих статей и нескольких лет кодинга на C# я заявляю: «ООП - это один большой обман. Никто не понимает, что это такое. Люди просто говорят какие-то умные термины, их собеседники с умным видом кивают, хотя на деле трактуют эти же термины совершенно по-разному».

И вот почему.

Читать далее

Такого «Посетителя» вы ещё не видели — Visitor.NET

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров9.4K


«Посетитель» (visitor) — один из самых сложных паттернов Банды Четырёх.

На языке C# для него можно создать множество реализаций, однако все они так или иначе имеют ограничения из-за возникающего динамического приведения типов.

В рамках статьи вы погрузитесь в проблематику мультиметодов и увидите новую реализацию паттерна, лишённую озвученных недостатков и открывающую возможность к написанию по-настоящему гибкого и типобезопасного кода!
Читать дальше →

Телеметрия, диагностики и компилятор

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров872

В современном мире невозможно себе представить взрослое приложение, которое не экспортирует телеметрию. Метрики — важнейший атрибут поддерживаемого софта; для всех более-менее профессиональных технических специалистов термин «visibility» давно вытеснил прочие остальные баззворды наподобие «test coverage» и «continious integration».

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

Отсюда вырос знаменитый «слоган» эрланга «Let It Crash!», высмеиваемый и всегда неверно трактуемый теми, кто неутомимо отслеживает все исключительные ситуации… и спотыкается об отсутствие нужного для их корректной обработки контекста в месте ловли. «Let It Crash» — означает не «Хрен с ними, с ошибками», а «Случилась какая-то ерунда в рантайме, но мы к ней готовы».

¡NB! В тексте нет прямых примеров использования телеметрии в ООП/ФП проектах, но я глубоко убежден, что этот текст будет полезно прочитать, даже если вы просто перекладываете джейсоны из пустого в порожнее на шарпах, котлине или хаскеле.

Telemetry it!

Иммутабельность и диоптрии

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров1.2K

Сегодня мы поговорим о еще одном, незаслуженно игнорируемом джейсоноукладчиками с узким кругозором, мощнейшем инструменте для работы со структурированными данными. О линзах. Удивительнейшим образом, поиск в интернетах по этому ключевому слову — из внятного — отдает только текст Эрика Эллиота с примерами на джаваскрипте. Эрик — умнейший человек и очень сильный популяризатор, но …кхм… «джаваскрипт, сэр».

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

Линзы: использование и абьюз

Классификация парадигм программирования

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров5.3K

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

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

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

Аспекты классификации

Как я создал систему безопасности для плагинов: от идеи до реализации

Уровень сложностиСредний
Время на прочтение13 мин
Количество просмотров1.4K

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

Читать далее

Разбираем архитектуру. Часть 1. Чистая архитектура и её корни: история и взаимосвязи

Уровень сложностиПростой
Время на прочтение24 мин
Количество просмотров14K

Предисловие

Цель этой статьи - объединить и кратко изложить все базовые архитектурные подходы: их терминологию, концепции и отличительные черты. Собрать всё воедино, чтобы можно было относительно быстро вникнуть в основы.

Я решил написать серию статей, посвящённых различным аспектам проектирования программных систем, но первоначальной идеей было показать архитектурное решение моего pet-проекта на FastAPI — пример реализации «чистой архитектуры» с использованием современного стека: Python3.13, FastAPI, Uvicorn, Nginx, PostgreSQL, Alembic, Celery, Redis, Pytest, Filebeat, Logstash, Elasticsearch, Kibana, Prometheus, Grafana, Docker и Docker Compose.

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

Читать далее

Ближайшие события

В центре внимания Java: Local Variable Type Inference, или var

Уровень сложностиСредний
Время на прочтение14 мин
Количество просмотров1.9K

Мы (команда Axiom JDK) подготовили перевод статьи про var, или Local Variable Type Inference (LVTI). Из этой статьи вы узнаете как работает var, когда эту фичу лучше использовать в коде, а когда — воздержаться. Всё это с примерами кода и комментариями от нашей команды.

Примечание от команды Axiom JDK: Хотя статья написана в 2019 году, она остаётся актуальной в 2025: var (Local Variable Type Inference) уже давно является частью LTS-релизов и ключевой особенностью современного Java-кода, но по-прежнему вызывает споры и вопросы даже у опытных разработчиков. Это отличный материал от Брайана Гётца — одного из архитекторов Java — с разбором принципов, которые не устарели. С тех пор появилось больше практики, но базовая теория осталась неизменной. Мы публикуем перевод как удобный справочник по механике var, его компромиссам и подводным камням.

Читать далее

ООП. Да что же ты такое?

Уровень сложностиСложный
Время на прочтение9 мин
Количество просмотров8.1K

Если меня на собеседовании спросят что такое ООП, то может получиться как в анекдоте " завыл, бился головой о стену, в общем ушёл от ответа". Любое простое определение ООП не полно, любое полное слишком сложно. Это показывает что ООП само в своих основах очень сложно, а на поверхности лишь видимая часть айсберга. Итак, пробуем дать краткое и герметичное определение, последовательно вводя минимум определений, чтобы были видны цели а не догма. Герметичное значит ясное и самодостаточное, не опирающееся (явно или неявно) на другие нетривиальные понятия. Всё по взрослому. Мне понадобилось много итераций. И на глубине я увидел чудовищ. Я конечно знал их и раньше, но думал что я просто дурак и не понимаю как просто с ними работать. Нырнул глубже и... они не пропали! Для любой сложной ООП системы они останутся с тобой.

ФП в отличие от него имеет крутую ступеньку входа но дальше сложность не растёт.

Habr, что это за поле «Целевая аудитория»?

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

Читать далее

Лучше самому изобрести колесо, чем ездить на арендованном квадратном

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров9.5K

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

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

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

Изобретайте колёса и стройте велосипеды!

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

Уровень сложностиСредний
Время на прочтение32 мин
Количество просмотров1.1K

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

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

Виртуальная СУБД является чисто объектной и не использует явным образом язык SQL, но это не означает, что она является NoSQL СУБД. Виртуальная СУБД - это чисто объектная система управления реляционной XML базой данных. Язык SQL реализован исключительно объектными средствами.   

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

Читать далее

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

Уровень сложностиСредний
Время на прочтение25 мин
Количество просмотров732

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

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

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

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

Читать далее

GRASP: почему настоящая архитектура начинается не с SOLID

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров51K

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

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

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

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

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

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

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

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

Читать далее

Тупиковый синьёр или при чем тут эрудиция?

Время на прочтение5 мин
Количество просмотров17K

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

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

А теперь про эрудицию и карьеру

Вклад авторов