Спустя годы проекты обрастают тёмными местами, в которые никто не хочет соваться, поскольку их сложно понять и легко сломать. Сегодня мы посмотрим на кейс рефакторинга такого кода с переводом на ООП рельсы при помощи паттернов, причём со стилем (современным).
Привет, хабравчане!
В первой части были рассмотрены паттерны проектирования 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 лет.
Привет, Хабр! К сегодняшнему дню написано уже немало учебников и статей по полиморфизму в целом и его воплощения в C++ в частности. Однако, к моему удивлению, при описании полиморфизма никто (или почти никто) не затрагивает тот факт, что помимо динамического полиморфизма в C++ имеется и достаточно мощная возможность использования его младшего брата – полиморфизма статического. Более того, он является одной из основных концепций STL – неотъемлемой части его стандартной библиотеке.
Поэтому в данной статье мне хотелось бы хотя бы в общих чертах рассказать о нём и его отличиях от всем известного динамического полиморфизма. Надеюсь, эта статья будет интересна для тех, кто только начал изучать принципы ООП, и они смогут посмотреть на его “третьего слона” с новой стороны.
Поговорили о перспективах С++, его особенностях и востребованности на рынке с Андреем Никитиным, ведущим инженером-разработчиком направления системного программирования Нижегородского подразделения компании «Криптонит».
С++ уже более сорока лет. В чём причина его популярности?
В плане семантики — это универсальный язык, но чаще С++ используется как объектно-ориентированный — с наследованием, интерфейсами и так далее. С++ позволяет строить что угодно — универсальные абстракции, иерархии любой сложности, логические слои, стеки протоколов... Обычно среди сильных сторон упоминают кроссплатформенность, но её нет «по умолчанию». Это не Java, программы на которой транслируются в байт-код и запускаются в виртуальной машине. В C++ нужно сразу писать код под все планируемые архитектуры и операционные системы, учитывать зависимые библиотеки. Всё это требует значительных усилий. Кроссплатформенность в С++ не данность, а отдельное требование, которое нужно учитывать на этапе разработки.
Почему С++ используют в «Криптоните» сейчас, когда есть более современные языки?
У нас в компании есть разные проекты. Некоторые из них начинались много лет назад, когда ещё не были популярны Rust, Golang и другие новомодные языки. При этом нам были важны требования производительности и «близости к железу». С++ был у всех на слуху. Он как раз обеспечивал сочетание высокоуровневого языка и возможность использования низкоуровневых функций. Сейчас мы продолжаем его использовать, потому что нет смысла портировать эти многолетние проекты на другие языки. Всё уже выверено и оптимизировано.
Как упростить себе жизнь или почему ты должен уметь создавать объекты правильно?
На этот вопрос я буду отвечать на протяжении всей статьи и уверен, что многим из вас, читающим данную статью, будет полезным знать, что такое осознанный подход при создании объектов в вашей кодовой базе.
Во второй части мы продолжаем усложнять наш пример, выдумывая различные требования, чтобы посмотреть на возможный путь эволюции создания объекта.
Рутина при написании кода неизбежна. Порой, соблазн скопипастить уже написанное, чуть подправив под задачу слишком велик. В статье показан один из множества способов выделить структуру рутинной задачи и помочь программисту не раздувать код бездумным копированием.
