ООП *

Основы

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

Сегодня я тебе объясню принципы 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 — принцип инверсии зависимостей

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

Приветствую всех укротителей событий! Проникнувшись идеей разработки с использованием DDD, я решил реализовать на нем обработку событий для элементов смарт-процессов Bitrix24, коей хочу поделиться с вами.

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

Роберт Мартин нехило так повлиял на айти‑индустрию. Он придумал принципы SOLID, о которых спрашивают на собесах, пишут статьи на хабре и спорят в комментариях. Он написал книгу «Чистый код» и сделал это словосочетание айтишным мемом. Если зайти на хэдхантер, вбить в поиске слово «чистый», выбрать специализацию «Программист, разработчик» и нажать «Найти», получим больше семисот вакансий. Про чистоту кода и архитектуры спорят на код‑ревью, в комментариях и статьях по всему интернету. Разговоров о чистоте внутри айти‑тусовки бывает так много, словно мы находимся в сообществе клинеров, а не программистов.

Мартин называет себя «дядюшкой Бобом». В своих работах он выступает в образе опытного мудрого и взрослого родственника, который несёт свет и знания таким зелёным и неопытным племянникам. И у него отлично получилось втереться в доверие! Типичный хороший программист‑анальник бессилен перед таким добрым дядей. И я знаю, о чём пишу. Восемь лет назад я сам запоем читал книги дядюшки, а потом до усрачки защищал чистоту кода на код‑ревью. Я на себе почувствовал, насколько Роберт Мартин отличный агитатор и пропагандист. Работая с другими людьми, читая статьи и обсуждения на Хабре и хакерньюс, анализируя требования к вакансиям, я понимаю, что не я один попался на отличную пропаганду от «дядюшки Боба».

В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.

Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.

SRP не SRP

Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).

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

Когда-то, лет 30 назад, мне посчастливилось поработать в одном очень продвинутом коллективе известного ВУЗа, и там один из научных руководителей регулярно приходил в бешенстве с конференций, на которых обсуждались видения ООП и подходы к реализациям, потому что его понимание сильно отличалось от коллег-участников конференций с других кафедр. Кстати сказать, он написал java-подобный язык, который вроде до сих пор с успехом используют. Этим воспоминанием я хочу подчеркнуть, что проблема не такая уж и новая, и не такая уж и надуманная.

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

Ну, посудите сами, парадигмы процедурного программирования основанные на теореме структурного программирования окончательно сформировались только к началу 70-х годов прошлого века, а первые языки ООП появились еще в начале 60-х годов. Но современное поколение, в основной своей массе, почему-то считает, что ООП - это что-то новое, и к тому же неудачное, и поэтому его надо срочно заменить чем-то типа Питона или на худой конец Скалы итп.