Всем привет! Предметно-ориентированное проектирование, на мой взгляд, является недопонятым подходом, о котором многие говорят, но немногие его действительно применяют.
Одним из относительно простых в реализации и полезных в архитектурном смысле паттернов, на мой взгляд, являются события предметной области (Domain Events). В данной статье я бы хотел рассказать о возможных вариантах реализации этого шаблона DDD с использованием .NET.
Бывают пет-проекты, а у нас получился проект с наработками, которые вроде бы могут быть полезны например студентам технических специальностей и просто всем кому интересно поразбираться с возможностями визуализации на C# + WPF, например, или с системой избыточного кодирования.
Мы со студентами сделали приложение для анализа характеристик LDPC кодов изначально на Java (Java код тоже присутствует в репозитории) потом я переписал его в виде проекта C# + WPF, чтобы добавить возможность конфигурации статистических экспериментов через визуальный интерфейс, а главное чтобы иметь возможность визуализации результатов экспериментов в виде графиков (обычных, в X, Y осях). Я как раз для работы сделал библиотеку для рисования обычных математических графиков по массивам значений с возможностью масштабирования области просмотра мышкой.
Думаю студентам любых технических направлений может пригодиться такая библиотека при том, что весь ее достаточно компактный исходный код (5-7 файлов) локализован в проекте и доступен как для изучения так и для любых изменений и доработок.
Под катом ссылка на Гит-репозиторий с исходным кодом и обзор реализованной функциональности со скриншотами.
Привет, хабровчане!
Я Дима, Python-разработчик из 21YARD, сервиса поиска строительных подрядчиков.
В статье расскажу о паттерне Интерпретатор. Разберемся, когда его использовать, какие концепции лежат в его основе. После используем паттерн, чтобы написать программу для решения математических выражений.
Статья про то, как я изменил стандартное поведение нормализации ввода и решил проблемы валидации, возникшие из-за этого. В статье упоминаются слова ООП, наследование, фабрики, сервис-провайдеры и другие.
Спустя годы проекты обрастают тёмными местами, в которые никто не хочет соваться, поскольку их сложно понять и легко сломать. Сегодня мы посмотрим на кейс рефакторинга такого кода с переводом на ООП рельсы при помощи паттернов, причём со стилем (современным).
Привет, хабравчане!
В первой части были рассмотрены паттерны проектирования Repository и Unit of Work.
Это вторая часть цикла о DDD. В ней расскажу, как добавить к проекту событийно-ориентированную архитектуру.
Код подопытного приложения ищите в репозитории по ссылке. Подробнее о DDD и паттернах Repository и Unit of Work читайте в первой части по ссылке...
Привет, хабр! Сегодня я хочу рассказать про свой опыт взаимодействия с языком kotlin.
Представлюсь – я java разработчик, работаю в крупном банке, создаю (и поддерживаю существующие) микросервисы.
Небольшая ремарка: я не собираюсь становиться Android разработчиком, ни сейчас, ни в будущем, поэтому, когда я заинтересовался новым языком, не принимал в расчет аргументы про различные удобства мобильной разработки на нем, и руководствовался только удобством языка в целом для бэкэнда.
Итак, почему я решил изучить kotlin. Ну, во-первых, прожужали все уши, мол сокращение объема код, лаконичность, читаемость и сахар.
В процессе написания приложения с более-менее сложной бизнес-логикой на фронтенде возникает необходимость держать всю эту логику на слое предметной области в "толстых" моделях. Например, для работы с формой, которая отображает на пользовательский интерфейс создание или редактирование сущности с большим количеством взаимозависимых свойств. Если "размазать" обработчики изменения состояния этой сущности и входящих в неё подсущностей по слою Application, легко можно потерять целостность модели в разных actions, reducers, валидаторах. Такой код будет трудно читать, отлаживать и поддерживать.
Можно использовать паттерн Aggregate Root для единой точки входа управления моделью, тогда упростится поддержка инварианта такой сущности. Методы доступа к свойствам и методы, меняющие состояние сущности, можно вызывать из одного объекта, а сам объект будет обеспечивать целостность и валидность своих данных. Но здесь появляется ещё одна проблема: сериализация. К примеру, бывает нужно сохранить всю сущность в каком-нибудь хранилище -- localStorage, redux store. Или отправить на бэкэнд для сохранения. Или событием обновить пользовательский интерфейс, а в payload события при этом надо передать часть сущности в виде простого плоского объекта. В этих случаях нам нужна выжимка данных из сущности, которую можно будет восстановить потом при запросе из хранилища для дальнейшей работы. Это особенно актуально, если на проекте используется SSR, там данные, которые собираются для страницы на серверной стороне, должны быть сериализуемыми.
Как абстрагироваться от Key-Value хранилища и забыть про бойлерплейт внутри репозиториев с помощью Kotlin делегатов
Статья посвящена теме ООП, истоков его создания и пояснения почему его стоит применять.
История начинается с того, что создатель ООП, Алан Кёртис Кэй, получил степень бакалавра по молекулярной биологии. Его интерес вызывали клетки организмов, их строение и поведение. Собственно чтобы не изобретать велосипед и использовать лучшие практики природы им и был создан этот подход к программированию, ООП.
Все ООП это попытка описать поведение клеток между друг другом, отсюда и энные принципы.
Изначально этот материал планировался как урок в PHP-курсе по полиморфизму. Но он, в конце концов, перерос сам урок, и я решил сделать из него отдельную статью. В ней практически ничего PHP-специфичного, поэтому рекомендуется для прочтения всем без исключения.
Напомню, что модель классов PHP взята из Java. Наличие интерфейсов и всех сопутствующих элементов очень сильно влияет на способ организации кода в PHP. Этот способ часто отличается от того, как организуется код в JavaScript, Ruby или Python. И ещё больше отличается от таких языков, как Clojure или Elixir. И всё это на фоне того, что в каждом из этих языков есть ООП.
ООП в этих языках настолько разное, что PHP-программисты, попадающие в Ruby или JavaScript, не понимают, как так можно писать, ведь многие подходы противоречат их представлениям о мире. То же самое происходит и в обратной ситуации.
Так где же правда? Правда в том, что есть вещи, которые действительно определяют архитектуру кода. И это не структура классов, не наличие интерфейсов и не использование полиморфизма.
Возьмём тот же MVC. В нём говорится о слоях, об их задачах (зонах ответственности) и способе взаимодействия друг с другом. Это крайне важно для модульности. В модульной системе отсутствуют циклические зависимости. В MVC ничего не говорится про классы и ООП в целом, потому что между этими понятиями нет связи. Реализовать MVC можно в любом языке общего назначения, каким бы он ни был. То же самое можно сказать обо всех других архитектурных шаблонах.
Архитектура опирается на особенности среды, в рамках которой она применяется, а не на конструкции языка. Например, в вебе господствует HTTP, который построен вокруг концепции "запрос-ответ". Именно поэтому микрофреймворки разных языков выглядят так похоже, независимо от того, есть там ООП или нет: в каждом микрофреймворке есть запрос, ответ и обработчик ответа.
Подробнее о разработке я пишу в своем телеграм-канале организованное программирование. Присоединяйтесь если статья понравилась :)
Привет, хабравчане!
В серии статей расскажу, что такое DDD (domain-driven design) и какие у него преимущества и недостатки. Разберемся, когда применять подход и как сочетать его с FastAPI, популярным ASGI фреймворком на Python.
В этой части рассмотрим паттерны проектирования Repository и Unit of Work. С их помощью мы работаем через интерфейсы. Паттерны помогают в разделении кода на слои: основная логика приложения представляется внутренними слоями, а используемые технологии - внешними.
В основе сборки любых компонентов лежит общий шаблон того, как они выполняют прокидывание зависимостей, это концепция, которую разработчики называют очень общим именем Inversion of Control (IoC: инверсия контроля). В этой статье я углублюсь в то, как работает этот паттерн под более конкретным названием «Dependency Injection» (Инъекция зависимостей), и сравню его с альтернативой - Service Locator
В мире программирования, особенно при разработке на Python, часто возникает необходимость не просто выводить статические строки, но и динамически встраивать в них данные, чтобы отобразить информацию пользователю в удобном и понятном виде. Это требует использования специальных методов, которые позволяют форматировать строки таким образом, чтобы они могли включать переменные, результаты вычислений и другие динамические элементы.
Эти методы как раз и называются - форматированием строк.
Expression Problem (EP) — это классическая задача в программировании на совмещение несовместимого.
Автор задачи (Philip Wadler) формулирует следующие цели: создать такую абстракцию, что позволяла бы расширять иерархию в двух направлениях: добавлять новые классы и добавлять новые методы для обработки иерархии, сохраняя при этом строгую статическую типизацию и не требуя изменений существующего кода.
В динамически типизируемых языках мы бы могли добавить или переопределить метод на лету с помощью трюка, ставшего известным под неказистым названием monkey patching (хоть первоначально речь шла совсем не про обезьян, а про партизан — guerrilla).
А вот какие трюки применяют в статически типизированных языках рассмотрим под катом.
Будучи автором серии статей о полноценной объектно-ориентированной игре "Морской бой", и вообще постоянно рассуждая об ООП в VBA, я вдруг понял, что, возможно, мне не удалось внятно объяснить, когда использование ООП в VBA действительно оправдано.
ООП — это парадигма, что подразумевает определённый способ мышления о коде. Функциональное программирование (ФП) — это другая парадигма, предполагающая иной подход к коду. Процедурное программирование также является парадигмой, где код представляет собой последовательность выполняемых команд. У каждой парадигмы есть свои плюсы и минусы, своя ценность и определённые задачи, которые решаются лучше всего именно в её рамках и,... конечно же, у каждой из них есть свои преданные приверженцы, которые уверены, что их путь – единственно верный. Не верьте всему, что читаете в интернете – мыслите о парадигмах как о разных инструментах: одна из них — молоток, другая — отвертка, третья — лопата.
Не нужно становиться членом команды "Молоток!", "Отвертка!" или "Лопата!" — всё это искусственные рамки. Разные инструменты лучше всего подходят для разных задач.
Поэтому первым вопросом, который вам стоит задать себе, это…
Всем привет, меня зовут Андрей, я — php-разработчик в wpp.digital.
Сегодня я поделюсь с вами историей. Она о том, как поверхностное понимание (или непонимание) паттернов проектирования отстрелило мне ногу. А еще поделюсь примером реализации простой истины: знание чего-то не равно умению это применять. Кстати, главным героем поэмы являюсь (неожиданная информация) я.
Кому будет полезен данный текст? В первую очередь, мне для рефлексии. Во вторую — той редкой породе новичков, которая умеет учиться на чужих ошибках. Ну и в последнюю очередь — опытным коллегам, которые могут поностальгировать по временам джуновых задач и огромных перспектив. Последние еще могут разнести в комментариях всё, что я здесь написал.
Теперь к задаче.
Мартышка и АйТи: Парадокс сложной эффективности
Вы когда-нибудь задумывались, почему в IT всё циклично? Почему старые методы и технологии, которые когда-то были на пике популярности, возвращаются на сцену?
Давайте разберёмся, что такое Парадокс сложной эффективности на простом примере, а также посмотрим, как это работает в IT последние 30 лет.
