ООП *

Недавно на подкасте Spring АйО мы обсуждали новые свитчи в Джаве — с паттерн‑матчингом и деструктуризацией. Я тогда ещё выразил мнение, что всё это неправославно, по‑зумерски и отход от принципов ООП.

Не от инкапсуляции, полиморфизма и наследования, а вообще от подхода. Новые свитчи будут провоцировать разработчиков писать код по‑новому, а не так, как завещали нам наши далёкие предки. С нарушением традиций, норм и устоев. Как учит Кейси Муратори, если вы понимаете о ком я.

Но какие они вообще были эти устои? Каким было ООП, когда всё только началось и чем это отличается от свитчей, до которых мы в конце концов докатились?

Библиотека функций к Script-fu

Итак, мы разработали практически полнофункциональную ООП систему для языка tinyscheme, так же работающую в script-fu GIMP. Но гложет меня одна мысль, реализовать поля общие для всех объектов класса. В разных языках они называются по разному, но смысл один, некие значения которые общие для всех объектов одного класса. В принципе как я уже указывал, такие поля реализуются как глобальные переменные, но реализация их в виде подсистемы ООП облегчит управление этими полями и использование их в обобщённых функциях. Тут есть тонкий момент: обобщённая функция может работать не только с объявленными типами параметров, но и с их наследниками. Если мы используем общие поля для класса в виде какой то глобальной переменной, то с этими полями могут работать не только объекты объявленных в параметрах классов, но и их потомки. И по идее методы обобщённой функции должны работать с типами соответствующим типам входных аргументов, а не просто типам объявленных параметров. А работа с глобальной переменной не будет различать одних потомков объявленных параметров метода от других. Во всяком случае такая персонализация работы будет затруднена и должна будет выполняться в ручную.

Библиотека функций к Script-fu

Написание кода на Лисп это тестирование, я не знаю(это не значит что их нет, просто я их действительно не знаю) ни одного языка программирования в котором цикл: написание код - проверка(тестирование) был бы таким коротким. Кстати в Script-fu я работаю через буфер обмена, это не удобно! Там есть возможность работать из Емакс, через сервер Scrip-fu, но я эту возможность не использую(приятно видеть консоль), а с обычной схемой или лиспом, работа в передаче кода заключается в нажатии пары клавиш. Лисперы не пишут многостраничные листинги кода, а затем его тестируют, они пишут функцию, выполняют его в интерпретаторе и сразу тестируют. Всё это благодаря наличию в системе REPL. И всё таки не смотря на это настаёт момент, когда требуются отдельные тесты, которые удобно запустить и проверить консистентное состояние программной системы, а то в процессе такого интенсивного создания-тестирования программы всё равно можно что либо опустить, и какая нибудь функциональность да отвалится.

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

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

Библиотека функций к Script-fu

Итак, теперь наша система позволяет описывать классы с иерархиями множественного наследования и описывать обобщённые функции(generic function) и они придают динамику, придают жизнь создаваемым в системе объектам. Но так ли хороши описанные нами обобщённые функции? Да с точки зрения широко распространённых("классических") ООП систем, они полностью повторяют функциональность методов объектов. При вызове обобщённой функции, происходит диспетчеризация вызова и выбирается наиболее подходящий по типам аргументов метод обобщённой функции. НО в CLOS это НЕ ТАК!!! Да в простейшем случае это так, НО..! CLOS предоставляет более гибкий способ организации кода, когда выполняемый при вызове обобщённой функции код представляет собой не один метод, а целую группу методов. Причём создаётся эта группа динамически в момент вызова, в зависимости от текущих аргументов обобщённой функции(вернее их типов/классов). А в основе такой организации кода лежит спецификация методов обобщённой функции различными квалификаторами.

Библиотека функций к Script-fu

Готовя эту статью я интересовался, что там в других языках, что там за «дженерики»? Все языки разбирать не буду, но скажу одно: Generic function использующиеся в ЛИСПе и современные дженерики различаются как НЕБО и ЗЕМЛЯ. За дженерики в современных языках в основном ратуют строго типизированные языки, всем понятно, что писать кучу однотипного кода просто глупо. Не скажу точно, кто стоит у истоков современных «дженериков», но пожалуй одним из ранних их проявлений это ШАБЛОНЫ в С++. Почему все остальные языки типа явы и ей подобных, решили назвать свои шаблоны дженериками мне не понятно. (у меня есть язвительное замечание, что хотели как в лиспе, но получилось как всегда). Но дело в том что в ПОДОБНЫХ дженериках языки с динамической типизацией просто не нуждаются. Функция list работает с любыми типами данных, ШАБЛОНЫ не нужны! А в С++ именно контейнеры стали основной побудительной силой использования дженериков, это просто хранилища которые хранят значения, если Си мы можем обойтись (void *) и потом привести тип к нужному, то С++ решил пойти по типобезопасному пути, ну немного "потолстев" в коде. Ну а что же там у современных его последователей?

Рассмотрим Go. Пытаясь избавиться от типа, вводят обобщённую переменную T, но понимая, что сделать то с ней ничего нельзя(кроме как хранить и выдать обратно), пытаются как то её ТИПИЗИРОВАТЬ!!! Вводят КОНТРАКТ! А что делать когда в функции надо будет делать сложение? Надо будет к этому контракту добавить ещё контракт аддитиве? а умножение? или ещё что то? в любом случае код функции БЕДЕН! именно в силу того что мы не знаем что может прилететь нам в типе Т. Я вам расскажу, что такое НАСТОЯЩИЕ ДЖЕНЕРИКИ.

Библиотека функций к Script-fu

Введение.

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

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

С необходимостью введения в язык Script‑fu Объектно‑ориентированного стиля программирования я столкнулся на поздних этапах реализации языка функциональной геометрии. Когда в коде появились «свичи/переключатели» и возможность исполнения кода в зависимости от типа входящих данных. Сам то этот «переключатель» написать не сложно, но в развивающемся проекте, постоянно возникают новые типы, изменяются, от каких то приходится отказываться, а ещё есть вариант создания модульных систем, когда в одном варианте существует один набор типов, а вдругом другой, ну а в третьем третий и т. д. И код этого «переключателя» постоянно приходится переписывать, или прибегать к различным «хакам», модифицирующим код в зависимости от того или иного варианта загрузки.

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

В мире разработки программного обеспечения управление состоянием объекта - одна из фундаментальных задач. Когда поведение объекта должно меняться в зависимости от его внутреннего состояния, разработчики часто обращаются к паттерну State. Однако здесь и возникает путаница: его нередко отождествляют с более общей концепцией — State Machine (Конечный автомат), а то и вовсе не видят разницы.

Погрузимся в мир управления состояниями — от простого к сложному!

Рассказываю как создать эхо-бота для MAX на Python с помощью библиотеки maxapi без проблем для aiogram разработчика!

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

Привет, Хабр! Меня зовут Константин Крюков, я разрабатываю систему хранения данных TATLIN.UNIFIED в YADRO. Сейчас мы с командой создаем MeyerSAN — решение, которое имитирует неисправность SAS HDD и SSD и позволяет автоматически тестировать реакцию СХД на ошибки.

Мы написали проект на новом стандарте С++ 23 и использовали паттерны объектно-ориентированного программирования. Под катом расскажу, что за решение у нас вышло, как устроена его архитектура. А еще мы вместе вспомним, зачем строить программную архитектуру тщательно и правильно (и не жалеть об утраченном времени на активную разработку).

QapDSLv2: Новый стандарт AST-heavy парсинга

QapDSLv2 обеспечивает:

Молниеносное построение AST

Полное сохранение структуры исходного кода

Простоту интерпретации и модификации грамматик

Забудьте о любы других парсерах! С помощью QapDSLv2 можно создавать компиляторы/анализаторы/форматировщики кода за минуты/часы.

Парсеры и генерация абстрактных синтаксических деревьев (AST) — это обычно долго, сложно и требует тонны шаблонного кода. Но что если я скажу, что теперь можно описывать грамматики и структуры данных одновременно и получать готовый, оптимизированный C++ код автоматически?

QapDSLv2 — новый стандарт эффективности и удобства в парсинге. Это язык описания парсеров, который избавляет от синтаксического шума, упрощает интеграцию с C++ и позволяет создавать сложные анализаторы без боли и ошибок. Забудьте о бесконечных циклах отладки и непонятных генераторах — теперь всё просто, понятно и эффективно.

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

Готовы ускорить разработку и вывести свои проекты на новый уровень?

QapGen — мощный генератор парсеров, построенный на основе QapDSLv2, который из грамматик QapDSLv2 сразу создаёт высокопроизводительный C++ парсер с типизированным AST, описанным прямо в грамматике.

t_sep{
stringbody =any(" \t\r\n");
}
using" "ast_sep;
t_value{
TAutoPtr<i_value> body;
" "?
}
t_comma_value{
","
t_value body;
" "?
}
t_array:i_value{
"["
" "?
t_value first?;
vector<t_comma_value> arr?;
"]"
" "?
}

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

Разработка — это не только про код, но и про подходы. В этой статье я постарался собрать и объяснить ключевые принципы проектирования, которые часто упоминают в собеседованиях, в статьях на Medium и в комментариях на GitHub, такие, как SOLID, DRY, KISS, YAGNI, APO, BDUF, бритва Оккама.

📌 Что внутри:

1. Понятные объяснения без перегрузки теорией

2. Примеры на Java (но подойдут и другим разработчикам)

3. Иллюстрации и метафоры, чтобы не уснуть

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

Привет! Меня зовут Азамат, я backend-разработчик в Циане. В работе мне часто приходится пересматривать архитектуру компонентов или проектировать её с нуля. Со временем у меня накопились подходы и наблюдения, которыми хочу поделиться.

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

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

Основная проблема IT-отрасли, на мой непросвещенный взгляд, заключается в том, что жизнь обучает нас профессии примерно так же, как учителя начальной школы — арифметике. Сначала нам говорят: делить на ноль нельзя. А потом оказывается, что ещё в XVII веке один маркиз по имени Гийом Франсуа Лопиталь научился. Нам говорят: квадратный корень можно извлекать только из положительных чисел. А потом — хоба — оказывается комплексными бывают не только обеды. И так далее.

С чего начинается обучение компьютерным наукам? — С некоторого количества теории, которая скучная и непонятная, как и любая полностью оторванная от практики теория, — а потом — с примеров. Мы открываем REPL и некоторое время забавляемся с ней, как с калькулятором.

Я не верю, конечно, ни в какую демократию (кроме оригинальной афинской 2½ тысячи лет назад, где кворум состоял из трёх с половиной образованных богатых неглупых людей, а остальные были безголосыми рабами и женщинами). Как я уже где-то говорил, существуют исторические свидетельства того, к чему привели первые проявления этой самой демократии: пару тысяч лет назад люди проголосовали распять одного там назаретянина.

Поэтому когда в качестве аргумента за ту, или иную парадигму, — я вижу какие-то индексы, голосования и прочую статистически значимую оценку vox populi, меня это раздражает. «Миллионы мух не могут ошибаться» — так себе аргумент. Поэтому мнение «коммьюнити разработчиков» — практически всегда облыжное, поверхностное, и, в целом, неверное. У каждого в руках свой молоток, а про многообразие саморезов люди en masse если и слышали, то краем уха и в качестве анекдота.

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

Доброго времени суток, Хабр!

Сегодня хотел бы поговорить об анемичной модели — одном из самых дискуссионных топиков (особенно для приверженцев DDD) и о том, как, по моему мнению, правильно её готовить. Для кого-то анемичная модель — это антипаттерн, тогда как для других это единственный правильный способ реализации приложений. Многие использовали её годами и даже не знали, как она называется, и что кем-то она считается антипаттерном. Реальность же такова, что анемичная модель — это инструмент, который может подходить или не подходить в зависимости от ситуации, но при этом является очень популярным и, по факту, «стандартом де-факто» для многих программистов и организаций. Хотя в последние годы я и вижу тенденцию к тому, что DDD и, соответственно, богатая доменная модель становятся всё популярнее, пока что, по моему мнению, им далеко до популярности анемичной модели.

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

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

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