ООП *

Привет, Хабр!

У меня появилась необходимость отделить проект от фреймворка. Благо кода фреймворка в проекте было не так много, но избавиться от него тоже нужно.
Поэтому было принято решение переписать функционал который он покрывал.
Одной из используемых функций фреймворка было - построение пространства имен.

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

Удачно получилось что тема пересекается с моей статьей. Может если это будет серия статьей с пометкой Клиентский код, то мне получится лучше донести что же всё-таки это за код такой.

Книги делятся на две категории: fiction и non-fiction. Технические книги — внезапно — не исключение, и поддаются точно такой же классификации. Между учебником по научной дисциплине, начинающегося с аксиоматики и продолжающегося доказательствами теорем, — и практически любой современной литературой по «Computer Science» — лежит пропасть. Что происходит, когда люди долгое время оказываются рабами одной-единственной книги (с продолжениями), нам хорошо известно из истории. Возникает религия.

99% процентов литературы по ООП — это талмуд. Вероятность того, что вам подойдет «паттерн» — примерно 50%. Как встретить динозавра на Невском. Знание паттернов полезно в той же степени, что и теология, — и примерно тем же по специальности людям. Всегда полезно уметь отличать по запаху Пана от простого фавна, но практических применений такой эрудиции — не существует.

Зайду с козырей: КДПВ этой заметки имеет прямое отношение к тексту.

Если вы сфокусируете взгляд на синей рамке, вы увидите растопырившего лапы Амбидиректуса с вытянутой шеей и маленькой головой, развернутой влево. Перефокусируясь на красную рамку, вы познакомитесь с его приготовившимся нырнуть в стену справа Alter Ego, с плотно ввинченной в шею головой и замершими во взмахе назад передними конечностями.

Я показал вам этого Амбидиректуса для того, чтобы проиллюстрировать основную мысль этого текста: споры о превосходстве той или иной парадигмы над остальными — не имеют никакого смысла и всегда являются религиозной войной остроконечников против тупоконечников.

Данная статья является продолжением серии статей посвященных Системе разработки клиентских приложений (KISS Virtual XML DBCS). В этой статье рассматривается синтаксис языка программирования ULCA (Universal Language for Client Application) , используемого этой Системой.

ULCA (Universal Language for Client Application) - Новый объектный интерпретируемый язык программирования, предназначенный для разработки клиентских desktop и web приложений. Данная статья является продолжением серии статей посвященных Системе разработки клиентских приложений (KISS Virtual XML DBCS). В этой статье рассматривается объектная модель, используемая языком программирования ULCA .

Основы

Привет, дорогой друг!

Сегодня я тебе объясню принципы SOLID максимально понятным способом.

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

Представь себе, что ты решил заняться бизнесом.

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

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

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

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

Но ты стоишь на страже интересов бизнеса! Железной рукой ты пресекаешь безобразия и вводишь жёсткий принцип – каждый сотрудник отвечает только за своё поле деятельности, у каждого своя ответственность, и никто в чужой огород лазать не смей. Закупщик – только закупает. Продажник – только продаёт. Каждый сотрудник должен иметь только одну зону ответственности.

Привет, Хабр!

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

Я честно, не знаю как в других профессиях, но в программировании, как мне кажется, собеседования — это чистая лотерея. Мое видение этого возможно подтверждает рынок труда — накрути себе опыта побольше, примени нейросеть, расскажи красиво о себе и вот работа (зарплата) мечты уже твоя. Следствием этого — по 300 отзывов на вакансию. Но, к слову, вакансии эти висят месяцами. Ты просто попадаешь в огромную кучу кандидатов, которых работодатель хочет отсеять и выбрать лучшего из вас. По каким критериям (по всем кроме трудовой книжки) вас будут сортировать одному Нео известно. Так‑же имел личный опыт, когда я отвечал полностью на все вопросы в течение часа. Получив оценку своим знаниям на 5+, заветную работу (зарплату) мечты я так и не получил.

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

Будет много схем и кода, демонстрирующих практические примеры применения паттернов Композит, Билдер, Визитер, Цепочка обязанностей и Декоратор. Не смотря на то, что примеры кода написаны на PHP, статья может оказаться интересной и для разработчиков, использующих другие языки.

Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных приложений (да и Android‑приложений тоже). Однако это семейство архитектур в контексте прикладной разработки зачастую не даёт никаких преимуществ, а только привносит лишние церемонии и тем самым замедляет её.

В этом посте я подробно разбираю, почему, на мой взгляд Чистая архитектура не является лучшим выбором по умолчанию для прикладных приложений, и кратко рассказываю об альтернативной архитектуре (спойлер: Промышленная функциональная архитектура), которую использую в качестве дефолтной последние 3 года и пока что доволен.

Но перед тем как перейти к Чистой архитектуре, сначала надо разобрать принцип инверсии зависимостей (Dependency Inversion Principle, DIP).

Привет! Хотелось бы поделиться с вами своей мудростью примером структуры, которая подойдёт практически для любых сервисов вне зависимости от того, гоняете ли вы JSON-ы в микросервисах или разрабатываете монолитное решение со сложной бизнес-логикой.

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

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

Если вы никогда не слышали об эффектах или термине "побочный эффект", рекомендую ознакомиться с этой темой для повышения вашего профессионального уровня и технического кругозора!

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

В системном дизайне понимание разницы между классами проектирования (design classes) и классами анализа (analysis classes) носит ключевой характер. Классы анализа подобны детективу — они исследуют и понимают проблему. Они сфокусированы на том, что система должна делать, без погружения в то, как именно это должно быть реализовано. Эти классы помогают разработчикам понять требования к программе и ее цели. В то время как классы проектирования подобно архитектору берут результаты изысканий классов анализа и создают план, как именно система будет работать.

Контекст

1. Программист / старший программист (сеньор),
2. Ведущий программист / лид,
3. Менеджер команды разработчиков/SEM (если я захочу развиваться как управленец).

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

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

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

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

Реализовав простейшую объектную систему в Scheme полезно было бы продемонстрировать преимущество от её использования. Чем в этой статье мы и займёмся. Демонстрацию проведём на примере абстракции Фигуры, ведь именно при реализации этой абстракции у меня и возникло сожаление об отсутствии ОО средств в Scheme.

Всем привет! Я Борис Зырянов, разработчик в команде Платформы. В этой статье хочу рассказать про Dependency Inversion Principle, потому что это, пожалуй, один из самых важных принципов SOLID, понимание которого дает ключи к архитектуре программного обеспечения. 

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

Маленькие заметки для тех, кому сложно понять кучу умных слов,

Single Responsibility Principle — принцип единственной ответственности

Open Closed Principle — принцип открытости-закрытости

Liskov Substitution Principle — принцип подстановки Барбары Лисков

Interface Segregation Principle — принцип разделения интерфейса

Dependency Inversion Principle — принцип инверсии зависимостей

Описания компоновки (управления автоматическим размещением визуальных элементов) которые мне попадались на родном языке мне кажутся не достаточно погружают читателя в реальную проблематику которая стоит за этим процессом. Мне хочется акцентировать внимание на том откуда берется сложность в этом вопросе. Хотелось бы чтобы кто-то покритиковал мои формулировки.