Блог

PHP. Не все ООП одинакого полезно.

Php не объектно ориентированный язык. Это язык с поддержкой ООП. По данным superjob, уверенные навыки обьектно-ориентированного программирования повышают стреднюю зарплату в 2 раза. Этот факт заставляет улыбнуться тех, кто пришел в php из Java или C++ программистов, ведь эти ребята считают, что систему сложнее, чем «Hello World» без ООП не построишь.

Меня давно волновал вопрос, где нужно использовать объекты, а где быстрее и проще процедурный подход. Дело в том, что у ООП есть ряд бесспорных преимуществ для абстрактного проекта в вакууме. Такой проект бесконечен по времени поддержки. Разарабатывают такой проект профессионалы высокого класса и обязательно все одного уровня. Система большая и сложная, а многие её элементы смогут стать отдельными системами. В таком проекте сначала строится структура, а потом уже пишется весь код. В нем важно общее время работы, а не время до запустка. Проще говоря, проект мечты, которого не бывает.

Но в реальных проектах часто все не так. И некоторые преимущества ООП могут стать недостатками. Стерлинг Хьюз (http://www.php.su/articles/?cat=common&page=004_2#11) считает, что неоправданное использование ООП — серьезная ошибка. Правда он писал это до того, как php существенно расширил поддержку ООП и часть его доводов устарели.

Я уверен в том, что каждое утверждение верно в рамках определенных условий. К примеру, не зависимо от того стоишь ты или идешь время течет одинаково. И это верно в нашей повседнейной жизни, но чтоит нам не побежать, а полетель на спутнике Глонасс и мы заметим, что время уже к вечеру начинает расходится на пару милисекунд. Этого вполне достаточно, что бы промазать ракетой на пару сотен метров, если не учесть релетявистские эффекты. Или другой пример. Каждый школьник знает, что вода кипит при 100 градусах. Но не каждый вспомнит, что это до того, как мы стали подниматься в гору.

Мне хотелось бы разобрать границы применимости ООП. Думаю, проще всего это сделать разобрав, когда преимущества ООП становятся недостатками. Преимущества возьму из книги «Object Oriented Programming with PHP5»

Пожалуй, самое главное преимущество возможность повторного использования, что налог не всегда будет 18%, а завтра станет, например, 22. И так далее. В итоге класс раздувается безусловно полезным функционалом. Но полезным кому-то, а не вам сейчас.

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

Следующее преимущество Рефакторингрефакторинг, ООП предоставляем вам максимум преимуществ, так как все объекты это маленькие элементы и содержат свои свойства и методы как часть себя. Чем больше проект, тем более эффективен будет рефакторинг и вообще любая оптимизация. Если код занимает всего 100 строк, то в общем то все равно, какой он. Конечно, читать говнокод никто не любит, но, скорее всего, даже средний программист сможет изменить там любую часть довольно быстро. Другой полюс - проект на тысячи файлов. Тут уже очень важно есть ли у проекта строгая и понятная структура. От этого время, затраченное на какое-то мелкое изменения меняется в десятки раз. Таким образом, чем больше проект, тем выгоднее ООП перед процедурным программированием. В небольших проектах, кстати, часто наоборот ООП выглядит слишком сложно и непонятно. Уровень при котором проект из небольшого превращается в большой у каждого программиста свой.

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

Тут главный критерий — на сколько начальная версия проекта больше (или меньше), чем итог. Этот фактор очень похож на первый, о времени поддержки, однако отличается от него. Если мы прекрасно заранее понимаем, что проект будет расширятся существенно и начальный функционал только «цветочки», то процедурное программирование, часто, плохой выбор. Плохой из-за того, что в момент очередного расширения функционала вы можете не найти уже реализованную функцию и напишите её заново. Мало того, что код продублируется и, в случае изменений, придется править в двух местах, так еще и очень вероятна ситуация, в которой через месяц вы будите править вторую функцию и не понимать, почему не меняется функционал, использующий первую. ООП само по себе не страхует от таких проблем, но оно существенно дисциплинирует и построить структуру.

Поддержка. Объектно-ориентированный код легче поддерживать так как он следует весьма жёстким соглашениям написания кода и пишется в самопоясняющейся форме. Тут опять применим первый фактор. Думаю, нет смысла повторяться.

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

На самом деле, это самое спорное преимущество. По тому, что даже с использованием ООП можно написать код так, что бы для отслеживания простейшего функционала приходилось «скакать» по 8 классам вверх и обратно. С другой стороны, процедурное программирование можно построить так, что бы соблюсти MVC и другие паттерны проектирования. Тут все зависит от архитектора проекта. Хотя, нужно признать, что ООП само по себе дисциплинирует. Думаю, фактор применимасти тут сам программист.

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

Ваше сообщение отправленно.