ООП в PHP 7: социальный кодинг и стандартизация кода
В продолжение темы объектно-ориентированной парадигмы в PHP поговорим о таких вещах, как социальный кодинг и стандартизация кода.
Социальный кодинг
Рассмотрим на следующем примере: есть два программиста - Вася и Петя. Вася написал для себя функцию, которая определяет расход бензина. Его функция принимает некий набор параметр для определения конечного результата. И Вася захотел поделиться своей разработкой на своем блоге, потому выложил свой код в архиве. А другой программист - Петя - тоже захотел определить расход бензина. Но писать ему подобную функцию с нуля не хотелось, потому он ее скопировал у Васи с блога, но только добавил пару своих параметров, которые будут учитываться при определении расхода бензина. И Петя решил у себя на блоге выложить эту функцию, только переработанную под себя.
И так, как Вася и Петя, поступили еще несколько (десятков, а может быть и сотен) программистов: скачали функцию определения расхода бензина у Васи, Пети (Ивана и так далее, таких было много), переработали под себя, и выложили на своих блогах.
Но позже Васе пришла идея немного доработать свою функцию определения расхода бензина и снова выложить на своем блоге уже обновленный вариант. И теперь Пете, Ивану и другим программистам, чтобы в своих проектах обновить эту функцию до последней, придется идти на блог Васи, скачивать функцию оттуда, распаковывать на своем сайте и перетирать старый вариант. Но это еще полбеды. После такого обновления у других программистов затрутся их доработки, которые они вносили ранее. И это может стать огромной проблемой (что и произошло по сути). С подобной проблемой пришлось столкнуться программистам, работающим с фреймворком Yii 1.0.
К тому же появилась некая необходимость стандартизации кода.
И чтобы подобных ситуаций не возникало, придумали такие вещи, как github, пакетные менеджеры (системы управления пакетами, packet manager), такие как:
- composer - пакетный менеджер зависимостей для PHP
- npm - NodeJS packet manager
- dpkg - используется в ОС Debian
- и другие.
И теперь, благодаря этим вещам, можно скачать любой из компонентов через пакетный менеджер, подгрузить в свой проект через autoload и работать с ним. А если нужно обновить какой-то из подключенных компонентов, то это можно делать одной командой из пакетного менеджера.
Стандартизация кода
А к чему же привела стандартизация кода?
Стандартизация кода появилась благодаря обмену кодом и опытом кодинга. Чтобы программистам понимать код других программистов, необходимо было определить стандарты (рекомендации, принципы), которых будут все придерживаться. И чтобы другие программисты могли использовать какие-либо общедоступные компоненты (или библиотеки), эти компоненты должны легко модифицироваться (дополняться, дорабатываться).
Здесь в качестве примера можно привести наиболее популярную CMS Wordpress. Использование CMS позволяет сделать из обычных страниц и записей полноценные блоги, интернет-магазины, соцсети благодаря использованию тысячи плагинов, компонентов, которые написаны другими программистами.
По тому же принципу и будут работать наши программисты Вася и Петя. Вася напишет свой компонент для определения расхода топлива в соответствии со стандартами, выложит его на github и packagist (из него загружаются компоненты через пакетный менеджер composer). А Петя загрузит компонент Вани через composer себе в каталог vendor (по умолчанию все компоненты из composer загружаются в этот каталог, а уже из этого каталога все подгружаются через autoload()) своего проекта, но для модификации "под себя" Петя уже будет модифицировать код не в самом компоненте, который находится в каталоге vendor, а будет расширять классы этого компонента и переопределять необходимые методы (принцип ООП - наследование). А если Ваня внесет изменения в свой компонент, то Петя сможет без каких-либо последствий обновить у себя этот компонент, а его изменения продолжат работать так же, как и работали до обновления компонента.