Данная статья посвящена разбору вопроса о том, какому именно объекту ООП должен принадлежать метод, осуществляющий взаимодейстие между несколькими сущностями.

Это распространённая тема для холиваров. Например:

Не используйте ООП. Никогда. Это ошибка.

На эту тему есть много материалов, к примеру: www.youtube.com/watch?v=QM1iUe6IofM

Если ООП все еще кажется вам хорошей идеей, то решите простую задачку.

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

Вопрос: методом какого класса будет являться метод.покормить()?

Просьба привести аргументированный ответ, в соответствии с иерархией классов, и другими лучшими практиками ООП.

Теперь сравните это с функциональной реализацией: у вас есть функция покормитьКошку() принимающая в качестве аргумента ссылку на кошку и кормушку.

Цитата из холивара

Как ответить на данный вопрос?

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

Наверное я не ошибусь, если скажу, что чаще всего на собеседованиях спрашивают о SOLID принципах. Технологии, языки и фреймворки разные, но принципы написания кода в целом похожи: SOLID, KISS, DRY, YAGNI, GRASP и подобные стоит знать всем.

В современной индустрии уже много десятков лет доминирует парадигма ООП и у многих разработчиков складывается впечатление, что она лучшая или и того хуже — единственная. На эту тему есть прекрасное видео Why Isn't Functional Programming the Norm? про развитие языков/парадигм и корни их популярности.

SOLID изначально были описаны Робертом Мартином для ООП и многими воспринимаются как относящиеся только к ООП, даже википедия говорит нам об этом, давайте же рассмотрим так ли эти принципы привязаны к ООП?

Привет, Хабр! Следующий этап изучения нового языка это старый добрый todo list c картинками. Чтобы научится работе с базой данных и файловой системой. Работе со стримами. За подробностями добро пожаловать под кат.

Давайте поговорим о high-load, high-extensible, ООП, DDD & EDA.

Речь пойдет о разнице между high load & high extensibility — это разные цели и задачи в разработке. Для которых нужны принципиально разные подходы. Которые часто вызывают когнитивный диссонанс среди программистов, предвещающий бурную полемику.

На Хабре много статей про high-load, а вот тема high-extensible как-то упускается из внимания.

Если попытаться примерно представить разность в понятиях и механиках, то вот табличка:

Давайте попробуем разобрать это все подробнее.

Все мы любим Spring. Или не любим. Но по крайней мере знаем. Если вы Java-программист, то вероятно используете этот фреймворк каждый день в своей работе. Spring — это огромная платформа, которая предоставляет большой функционал. Тем не менее во главе угла стоят две вещи — это DI (Dependency Injection) и IoC (Inversion of Control). Концепции, которые были призваны, чтобы сделать наш код более читаемым и поддерживаемым. Но к несчастью, все оказалось не так радужно. Именно это мы сегодня и обсудим.

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

Основная мысль — в середине 2017 года я инициировал смену основного стека разработки бэкенд приложений, разрабатываемых нашей компанией с .Net (C#) на Node.js (typescript). Как это вышло, жалею ли о принятом решении и не собираюсь ли назад? Об этом ниже.

Цель данной статьи — не выбор лучшей из двух платформ, а поиск сильных и слабых сторон каждой из них. Обе технологии прочно зарекомендовали себя в мире веб-разработки. Каждая из них имеет своих фанатов, получивших хорошие результаты и делящиеся своими достижениями на просторах интернета. В сети имеются многочисленные отзывы о тех преимуществах, которые получили разработчики при переходе на .Net Core или Node.js. Попытаемся разобраться в этом.

Сегодня речь пойдет про одну интересную идиому, которую ввел Шон Парент (Adobe) — известный деятель в C++-сообществе. Он часто выступает с докладами и публикует цикл статей Better Code. Одна из его идей, которую используют в Photoshop — это Concept-Based Polymorphism. Это когда мы реализуем полиморфизм не через явное наследование, а с помощью техники, включающей обобщенное программирование, и по итогам получаем некоторые дополнительные преимущества.

Статья устроена следующим образом:

1. Что вообще такое Concept-Based Polymorphism и зачем он нужен
   
2. Немного про LLVM и ее устройство
   
3. Пример Concept-Based Polymorphism в LLVM PassManager
   
4. Преимущества подхода
   

Картинка, иллюстрирующая тезис «Наследование — это зло». Источник

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

Но все ли до конца понимают, что эти слова означают?
Все ли понимают что такое модель и как она должна выглядеть

Давайте порассуждаем (и не только) на эту тему.

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

Привет, Хаброжители! Больше 25 лет прошло с момента выхода первого тиража книги Design Patterns. За это время книга из популярной превратилась в культовую. Во всем мире ее рекомендуют прочитать каждому, кто хочет связать жизнь с информационными технологиями и программированием. «Русский» язык, на котором разговаривают айтишники, поменялся, многие англоязычные термины стали привычными, паттерны вошли в нашу жизнь.

Перед вами юбилейное издание с обновленным переводом книги, ставшей must-read для каждого программиста. «Паттерны объектно-ориентированного проектирования» пришли на смену «Приемам объектно-ориентированного проектирования».

Четыре первоклассных разработчика — Банда четырех — представляют вашему вниманию опыт ООП в виде двадцати трех паттернов. Паттерны появились потому, что разработчики искали пути повышения гибкости и степени повторного использования своих программ. Авторы не только дают принципы использования шаблонов проектирования, но и систематизируют информацию. Вы узнаете о роли паттернов в архитектуре сложных систем и сможете быстро и эффективно создавать собственные приложения с учетом всех ограничений, возникающих при разработке больших проектов. Все шаблоны взяты из реальных систем и основаны на реальной практике. Для каждого паттерна приведен код на C++ или Smalltalk, демонстрирующий его возможности.

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


Изображение из блога Фаулера: TellDontAsk

Вступление

Знаете, что я не люблю? — Я не люблю, когда мне приходится через раз вылезать из моей уютной IDE, чтобы посмотреть в документации по API какого-то сервиса, какие там параметры есть в очередной сущности. Ну серьезно, некоторые сервисы если и создают свой SDK/обертку или что у них там, то мало кто озаботится тем, чтобы реализовать взаимодействие пользователя с оберткой посредством преобразователя данных (Data Mapper). А ведь это может сильно упростить жизнь простым смертным разработчикам при использовании API.

В связи с этим, я решил написать свой велосипед собственную обертку для API Битрикс24 на PHP, т.к. официальная — оставляет желать лучшего в вышеописанном плане.

В статье я:

• опишу образ моего мышления при обдумывании архитектуры по принципам GRASP и SOLID
• выстрелю себе в ногу, а затем исправлю ситуацию
• разработаю прототип с первыми сущностями и методами

UPD 1: Статья устарела
Используйте feature-sliced.design
UPD 2: ещё у меня есть Telegram-канал, где я собираю ссылки на свои статьи про разработку, развитие SaaS-проектов и управление IT-проектами.

Добрый день, уважаемые читатели. В этой статье мы поговорим об архитектуре программного обеспечения в веб-разработке. Довольно долгое время я и мои коллеги используем вариацию The Clean Architecture для построения архитектуры в своих проектах Frontend проектах. Изначально я взял ее на вооружение с переходом на TypeScript, так как не нашел других подходящих общепринятых архитектурных подходов в мире разработки на React (а пришел я из Android-разработки, где давным-давно, еще до Kotlin, наделала шумихи статья от Fernando Cejas, на которую я до сих пор иногда ссылаюсь).

В данной статье я хочу рассказать вам о нашем опыте применения The Clean Architecture в React-приложениях с использованием TypeScript. Зачем я это рассказываю? — Иногда мне приходится разъяснять и обосновывать ее использование разработчикам, которые еще не знакомы с таким подходом. Поэтому здесь я сделаю детальный разбор с наглядными пояснениями на которое я смогу ссылаться в будущем.

Аннотация:

1. Пример реализации нового функционала в классе через добавление «флажка».
2. Последствия.
3. Альтернативный подход и сравнение результатов.
4. Как избежать ситуации: «Архитектурный оверкилл»?
5. Момент, когда приходит время всё менять.

Вступление

Название поста действительно «холиварное», но на мой взгляд и у Java, и у популярной библиотеки Guava есть ряд архитектурных проблем, которые в перспективе приводят к двусмысленностям и разногласиям в команде.

Привет, Хабр! Представляю вашему вниманию перевод оригинальной статьи «Your C# is already functional, but only if you let it» автора Igal Tabachnik.

Несколько дней назад я написал в Твиттере фрагмент кода C#, реализующий FizzBuzz, используя некоторые из новых «фичи» в C# 8.0 . Твит “стал вирусным”, несколько человек восхищались его лаконичностью и функциональностью, в то время как другие спрашивали меня, почему я не написал его на F#?

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

«Он выглядит слишком функциональным.» – писали мне они.

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

Спустя годы после выхода "Domain-Driven Design", идеи Эванса вошли мейнстрим. Разработка через моделирование должна была уменьшить неопределенность, позволить разрабатывать ПО за меньшее число итераций. Должна была, но ничего не вышло.

На собеседованиях и митапах я слышу

Мы пытались внедрить DDD, но у нас не получилось

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

Под катом: 5 способов провалиться на внедрении DDD

Всем привет, меня зовут Константин. Я занимаюсь разработкой на Java в Tinkoff.ru и люблю SOLID. В этой статье мы сформулируем принцип подстановки Лисков, покажем его связь с принципом Открытости-Закрытости, узнаем, как правильно формировать иерархию наследования и ответим на философский вопрос о том, является ли квадрат прямоугольником.