ООП *

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

В данной статье рассматривается реализация ООБД в контексте разработки системы, состоящей из микросервисов, на примере Perst и Db4o. Также будет рассмотрена отдельная реализация с документно-ориентированной базой данных MongoDB, работа с которой имеет много общего с ООБД.

Целью данной статьи является рассмотрение практического применения ООБД и решения проблем совместимости с помощью микросервисной архитектуры.

Привет! Меня зовут Айнур, и я frontend-разработчик SimbirSoft. Более 6 лет я работаю над коммерческими проектами, создаю и улучшаю интерфейсы, поэтому в работе достаточно часто использую паттерны проектирования. Неоднократно я обращался за идеями и лайфхаками к книге Patterns.dev, которая содержит очень современный взгляд на шаблоны проектирования, рендеринга и производительности JavaScript.

Авторы Patterns.dev:

Лидия Холли — штатный консультант и преподаватель по разработке программного обеспечения, которая в основном работает с JavaScript, React, Node, GraphQL. Она также занимается наставничеством и проводит личные тренинги.

Эдди Османи — технический менеджер, работающий над Google Chrome. Его команды работают над такими проектами, как Lighthouse, PageSpeed ​​Insights, Chrome User Experience Report и другими.

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

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

Источник: https://www.patterns.dev/
Данный адаптированный материал распространяется на условиях лицензии Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)

Добрый день!

Язык Python для меня не является языком программирования, который я использую в повседневной работе. Для меня более близки ООП языки программирования Java, Object Pascal. Поэтому, не холивара ради, я хочу спросить у сообщества на сколько правильно решение, которое я опишу в данной статье?

Когда речь заходит об авторизации, роли вступают в игру. Если модель плоская, то все просто. Пользователь обладает определенным набором привелегий и при запросе достаточно лишь проверить, что нужное право доступа присутствует в коллекции. Но как быть, если у пользователя могут быть разные наборы ролей для разных сущностей? Например, я обладаю ролью EDITOR в посте в социальной сети, но имею только VIEWER в другом. Также могут быть определены правила наследования. Если админ выдает дает мне роль EDITOR, то я автоматически приобретаю привилегию VIEWER. При этом, если я EDITOR, роль ADMIN у меня не появляется.

Как увязать все эти детали в коде и при этом не превратить продукт в большую кучу грязи? В рамках этой статьи я расскажу вам:

1. Как реализовать наследование ролей в Java?

2. Как протестировать полученную иерархию?

3. Как применить решение в рамках Spring Security?

Здравствуйте, меня зовут Дмитрий Карловский. А вы на канале Core Dump, где мы берём различные темы из компьютерной науки и без лишней зауми раскладываем их по полочкам.

В далёком 1988 году Бертран Мейер сформулировал свой принцип написания кода долгоживущих проектов под названием «Принцип открытости/закрытости» или OCP.

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

Привет! Меня зовут Грант, я .Net-разработчик. Знаете вы это или нет, но ваш код можно переиспользовать: будь то модуль, компонент или архитектура. Одни разработчики делают это осознанно, другие на уровне рефлексов. Повторное использование хорошего кода экономит время и другие ресурсы, позволяет применять лучшие практики на проектах, чтобы в итоге эффективнее решать бизнес-задачи.

Мне стало интересно разобраться, когда возможен code reuse, какие проблемы стоит предусмотреть, и какие ресурсы заложить при реализации проектов. Для этого я проанализировал более 30 источников, в том числе иностранных, и вспомнил свой личный опыт на проектах. Разберу классификации механизмов повторного использования и расскажу о своей, покажу примеры разных масштабов: от уровня нескольких операторов до уровня архитектуры.

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

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

SOLID — универсальный набор принципов разработки поддерживаемого программного обеспечения. В данной статье я попытался разъяснить свое понимание принципов SOLID в отношении языка JavaScript: особенности реализации, некоторые синтаксические конструкции и, конечно, примеры из жизни. Если вам стало интересно, то прошу под кат.

Так выглядит "инкапсуляция, наследование и полиморфизм" в глазах Midjourney. Интересно, кто тут кто, а так же какой четвёртый "кит" ООП закрался в эту мозаику. Но я не об этом. Я собрал студентам конспект своих лекций по ООП, которые читаю уже, страшно подумать, больше 15 лет. Книжку по функциональному программированию я написал уже давно, книжка по реляционным базам данных пока только в виде первой главы, а конспект по ООП собрался только вот-вот, аккурат к сессии готовиться. Не знаю, что из этого выйдет, %хабр%, "но так и быть - рукой пристрастной прими собранье пестрых глав". Содержание всех глав - в конце, а под катом - одна из глав, которая посвящена SOLID. Да, опять. Да, снова.

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

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

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

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

Прошлый раз я сказал, что C# не поддерживает двойную диспетчеризацию. Это была наглая ложь! На самом деле C# поддерживает множественную диспетчеризацию. Вы можете выбрать метод на основании типа времен выполнения любого количества аргументов.

Итак, давайте отвлечемся на несколько эпизодов. Мы временно оставим в стороне проблему того, как мы можем иметь и Игрока с Оружием, и Волшебника с Посохом (или Кинжалом). Предположим, что мы можем все это представить в виде типов.

У нас есть еще одна проблема. Предположим, у нас также есть классы Оборотней и Вампиров, которые являются разновидностью Монстров. Нам нужно правило, которое гласит, что если Воин попытается ударить Оборотня после полуночи, то вероятность успеха будет снижена. (У волшебников нет такого штрафа, потому что… магия?)

Подождите минутку — разве текущий момент времени это не после полуночи всегда? Короче, когда можно безопасно кормить могваев? Хотя это увлекательная проблема, я уверен, что это не та проблема, о которой я хочу говорить сегодня.

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

(Если вы не читали первую статью серии, то обязательно начните с нее)

Распространенная проблема, которую я вижу в объектно-ориентированном проектировании:

* Волшебник — это разновидность игрока.
* Воин — это разновидность игрока.
* У игрока есть оружие.
* Посох — это разновидность оружия.
* Меч — это разновидность оружия.

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

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

Для кого статья

Вы уже написали свои первые 1000 строк кода и сейчас хотите сделать их понятнее, потому что внесение изменений занимает столько-же времени, сколько написать заново, но советы из ООП, SOLID, clean architecture и т.д. непонятны вам.

О чем статья

Эта статья - не объяснение принципов ООП, SOLID своими словами, а попытка создать промежуточный уровень между никакой и чистой архитектурами. 100% советы будут накладываться друг на друга и перефразировать SOLID, но так даже лучше.

От кого статья

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

Отказ от ответственности

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

Формат статьи - наводящие советы / вопросы.

Здесь онлайн интерпретатор, здесь документация.

В сентябре 2020 года я учился на 2 курсе. В том же месяце я впервые написал программу, которая мне понравилась. Она создаёт svg изображения растений, здесь её можно потрогать.

Чуть позже я выяснил, что такие программы называют процедурными генераторами. Я увлекся этим, сделал ещё парочку (1, 2).

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

Вы знали, что AutoMapper и MediatR создал один и тот же человек?

Джимми Богард создал две крайне обсуждаемые и спорные темы в .NET разработке. Если с MediatR уже разобрались, то c AutoMapper также хотелось бы расставить все точки над "ё".

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