ООП *

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

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

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

Что получится, если попытаться описать составной объект? Как ни старайся, ничего другого, кроме древовидной структуры у вас не получится. Отсюда первый принцип:

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

Мы видели два варианта решения проблемы:

Всем привет.

Данная статья будет полезна начинающим Java разработчиком понять зачем нужен шаблон проектирования «Цепочка ответственности» и как его можно использовать на примерах.

Итак начнем с самого начала. Основная суть данного шаблона: связывание объектов‑получателей в цепочку и передача запроса по ней.

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

«Почему сейчас программисты меньше говорят о паттернах проектирования? Какие паттерны (если они есть) все еще представляют ценность?»

На собеседовании:

- Как у вас с Экселем?

- Я его ненавижу!

- О, да вы VBA-разработчик!

Я не могу открывать здесь Америк, ибо не технарь, но раз тут был чей-то текст, как написать "Hello world" в Word'e, и всем понравился, то думаю, что нелишним будет и мой небольшой опыт.

п1. Как обычный пользователь пишет макросы в эксельке

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

Ну, например, очень редко для обращения к ячейке употребляется метод Cells с индексами номера строки и колонки, по большей части используют уродцев типа Cells("A"&(i+1)) , а переход к следующей ячейке делают через Offset (и. что интересно, код работает - умудряются не запутываться в сдвиге А относительно Б, С относительно Б и так далее, могу только предположить, сколько такую связку из офсетов отлаживают). Массивов в их классическом виде средний российский макрописец не признает в принципе, и я догадываюсь, что он просто не знает, что есть такая сущность, и все переборы и вычисления проводит. обращаясь напрямую к ячейкам (хотя сансэй Уокенбах в каждой книжке повторяет, что массивы работают на порядок быстрей).

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

В данной статье рассматривается реализация ООБД в контексте разработки системы, состоящей из микросервисов, на примере 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# поддерживает множественную диспетчеризацию. Вы можете выбрать метод на основании типа времен выполнения любого количества аргументов.