ООП *

Всем привет! Я Борис Зырянов, разработчик в команде Платформы. В этой статье хочу рассказать про 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-х годов. Но современное поколение, в основной своей массе, почему-то считает, что ООП - это что-то новое, и к тому же неудачное, и поэтому его надо срочно заменить чем-то типа Питона или на худой конец Скалы итп.

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

Вот уже 20 лет я преподаю программирование в университете Буэнос-Айреса. На курсе программной инженерии мы изучаем паттерны проектирования, и одна и та же «схема» повторяется раз за разом, вызывая почти де жа вю. Я убедился в этом на нескольких проектах и при обращении со свободным ПО, которым мне приходилось пользоваться:

Как «по волшебству» в коде возникает паттерн синглтон.

Автор: Денис Закусило

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

[Записки тимлида] Битрикс: от модулей к сервисам

[Записки тимлида] Битрикс: от модулей к сервисам 2

Сегодня мы рассмотрим организацию структуры frontend стороны приложения.

Последние год-полтора я натыкаюсь на статьи и доклады (особенно в англоязычном сегменте) о том, что JOOQ – это современная и более крутая альтернатива Hibernate.

Скажу сразу, что я считаю JOOQ отличной библиотекой (именно библиотекой, а не фреймворком, в отличие от Hibernate). Он прекрасно справляется со своей задачей – работой с SQL в режиме статической типизации, чтобы отловить большинство ошибок на этапе компиляции.

Но когда я слышу аргумент, что время Hibernate прошло и пора все писать на JOOQ, для меня это звучит примерно так же, как то, что время реляционных БД прошло и теперь нужно использовать только NoSQL. Звучит смешно? Но по меркам истории буквально вчера такие разговоры велись вполне серьезно.

Я думаю, дело кроется в непонимании корневых проблем, которые решают эти два инструмента. Этой статьей я хочу ответить на эти вопросы.

Зачастую, когда речь заходит про принцип инверсии зависимостей, можно услышать, что инверсия зависимостей (далее DIP) — это что-то там про зависимость от абстракций, и приводятся примеры, где в качестве «плохого» случая, используются конкретные классы, а в исправленном случае, используются абстрактные классы или интерфейсы. Но такая трактовка принципа в корне неверна.

Почему такая трактовка неверна и в чем же суть принципа — об этом и пойдет речь далее.

Сегодня я расскажу, как можно создать собственную систему репутации с Telegram на Python. Решение будет легким и красивым, обещаю.

⌚️Пишем Realtime для Multiple-page application в микросервисной архитектуре

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

В статье описывается, как отправить пропущенные во время переподключения события WebSocket повторно в порядке очередности поступления

📦 Четыре пункта, как улучшить код Backend стажера

В статье разобраны распространенные проблемы в коде начинающих разработчиков с конкретными решениями: грамотная инъекция зависимостей, использование Scoped-сервисов, паттерн Generic Repository и создание Stateless-классов. Материал будет полезен Junior и Middle разработчикам, которые стремятся улучшить архитектуру своих проектов и избежать ошибок структурирования кода в backend NodeJS разработке

Здравствуйте, друзья! Меня зовут Константин, я python backend developer из компании «Окенит». Сегодня я хочу рассказать свое видение проблемы новичка при ознакомлении с принципами SOLID, описанными в книге «Стерильная Архитектура» Робина Мартерта.

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

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

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

ORM позволяет абстрагироваться от сырых SQL запросов путем абстракций.

В этой статье мы и рассмотрим создание своей ORM на Python с документацией и публикацией на PyPI. Данный проект очень интересен со стороны реализации: ведь требуется изучить большую часть ООП, принципов и паттернов.

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

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

Паттерны проектирования - проверенные временем решения общих задач в программировании. Они разделяются на три категории:

Отсутствие четкой структурированной архитектуры проектов — не редкость в ИТ. Одни этим пренебрегают из-за маленького масштаба проекта, другие — из-за сжатых сроков разработки, третьи — из-за отсутствия экспертизы в этом вопросе. Вместе с тем, движение по этому пути — практически всегда история с «отложенными последствиями»: со временем такие проекты становится сложно поддерживать, масштабировать, администрировать и фиксить. 

Меня зовут Никита Дергачев. Я Teamlead COOL TEAM в MedTech компании СберЗдоровье. В этой статье я расскажу, почему важно структурировано выстраивать архитектуру проектов, а также покажу на примере, с помощью каких инструментов можно отслеживать соответствие архитектуры изначальным требованиям.

Интерфейсы — одна из самых сложных тем для начинающих в Go. Я решил тщательно разобраться с этой темой и одновременно написать эту статью. После прочтения этой статьи вы сможете ответить на следующие вопросы:
Что такое интерфейс? Что такое значение интерфейса? Что такое пустой интерфейс? Почему nil-интерфейс не равен nil? Где разместить интерфейс? Какая структура интерфейса?