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

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

Но что такое парадигма?

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

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

Ресурсно-ориентированное программирование

Не зная об этом, с появлением фреймворков (например, Symfony или Laravel) в сочетании с принципом MVC (Model View Controller) также было введено понятие Ресурсно-ориентированное программирование. Но что именно представляет собой это понятие?

Можем ли мы уточнить, что такое ресурс?

Во-первых, чтобы было ясно, давайте определим ресурс. Вы должны видеть ресурс как данные определенного типа. Например, Fiat 500 – это ресурс Автомобиль, а Джонатан – ресурс Пользователь.

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

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

Но каковы пределы программирования, ориентированного на ресурсы? Мы можем столкнуться с тем, что кодируем одно и то же поведение много раз и вынуждены дублировать код во многих скриптах, даже если, к счастью, можно разложить на множители, используя наследование или трейты. Во всех случаях, как правило, будет по крайней мере один контроллер для каждого типа ресурса. Это не проблема, если вам нужно управлять 4 или 5 различными типами. Но представьте, что нам приходится управлять 100, 200 или даже 500 различными типами ресурсов? Представляете ли вы, что вам нужно дублировать свой код столько раз и воссоздавать снова и снова управление добавлением, просмотром, редактированием, удалением…?

Что, если бы мы поступили иначе?

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

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

Хорошо, но как мы это сделаем?

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

  • CreateController
  • Получитьконтроллер
  • UpdateController
  • Удалитьконтроллер

Каждый контроллер будет специализирован для выполнения своих конкретных функций, независимо от типа ресурса. Например, CreateControllers сможет создавать автомобили, пользователей, дома или компании. Таким образом, функционально-ориентированное программирование является универсальным и гибким. Он должен быть в состоянии адаптироваться независимо от того, каким типом ресурса вы хотите управлять.

Вы видите преимущество? На самом деле, управляете ли вы 1, 5, 10, 100 или 500 различными типами ресурсов, у вас всегда будет только 4 контроллера! Работа сделана раз и навсегда.

Хорошо, но если мы хотим делать определенные вещи для определенных ресурсов?

Здесь вступает в действие еще один очень полезный принцип: переопределить. Скажем так, благодаря Функционально-ориентированному программированию мы сможем ответить примерно на 80% самых актуальных запросов. Для оставшихся 20% необходимо разрешить переопределение поведения по умолчанию. Давайте представим, что когда пользователь регистрируется на сайте (таким образом создается новый пользователь), мы хотим отправить ему электронное письмо. Это специфическое поведение, потому что вы никогда не хотите отправлять электронное письмо во время создания, за исключением случаев, когда это пользователь. Для достижения этой цели мы можем создать специальный CreateUsersController, который будет расширять CreateController, но также будет иметь метод для отправки электронного письма после создания.

Что, если мы хотим сделать что-то совершенно конкретное?

Действительно, нам может понадобиться совершенно специфическое поведение, которое мы не найдем больше нигде. Например, аутентификация только для пользователей… Нет проблем!

Как говорится, «кто может больше, тот может меньше». Как и в примере с игрушками, которые можно классифицировать сначала по категории, а затем по цвету, можно использовать Ресурсо-ориентированное программирование в проекте, который использует Функционально-ориентированное программирование (обратное менее очевиден…). Ничто не мешает создавать специальные контроллеры.

Чтобы удовлетворить потребности, мы могли бы, например, создать AuthController, который будет управлять только аутентификацией пользователя (регистрация, идентификация, утерянный пароль).

Подводя итог, можно сказать:

  • Оставайтесь универсальными, насколько это возможно
  • При необходимости используйте переопределение
  • Займитесь конкретной разработкой, если у вас нет выбора

Есть ли ограничения?

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

Если он приучит свой ум мыслить «обобщенно», разработчик сможет перейти от простого исполнителя к истинной силе предложения! Какой пользователь будет жаловаться на то, что ему предлагают обобщить его функционал на другие ресурсы?!

Какую парадигму выбрать?

Итак, программирование, ориентированное на ресурсы или программирование, ориентированное на функциональность? Так и хочется сказать, что это зависит от проекта и пользователей, которым адресовано приложение.

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

Поговорим о деньгах?!

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

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

Или почему бы не договориться с вашим заказчиком об использовании ядра для других заказчиков? Работа будет сделана один раз, и все, что останется, это настроить некоторые вещи в соответствии с потребностями.

Вывод

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

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