Нужно ли ооп в php
PHP — ООП или процедурный подход
PHP один из самых популярных скриптовых языков программирования. Почти 60% веб серверов используют PHP.Миллионы веб-сайтов и веб-приложений разрабатываются на PHP каждый месяц.
PHP изначально разрабатывался как простая замена языку Perl, и уже спустя пару лет он стал чрезвычайно мощным и популярным. Язык PHP, сам по себе очень похож на ANSI C.
Одна из причин почему PHP стал таким популярным это его короткий период обучения.
Изучение PHP абсолютно не тяжёлое занятие, особенно если вы хорошо знакомы с синтаксисом Java или C.
Так как писать PHP скрипты достаточно просто, любой может написать PHP код без соблюдения каких-либо соглашений и смешивая уровень представления с бизнес логикой (это одна из основных причин существования большого количества неуправляемых проектов). Потому что в PHP не обязательно строгое соответствие соглашений написания кода, с годами когда проект становится всё больше и больше, он превращается в громадное неуправляемое приложение.
ООП или Объе́ктно-ориенти́рованное программи́рование хорошо применяется в практике программирования для более лёгкого создания управляемых проектов.
Процедурный подход подразумевает написание программного кода без использования объектов. Процедурное программирование заключается в написании кода с или без подпрограмм.
ООП обучает любой язык программирования более хорошему программному коду и используется, для получения более высокой производительности и написания больших проектов, не боясь запутаться в их управлении. ООП даёт вам возможность создавать объекты которые можно будет использовать многократно, для того что бы вы или другие разработчики могли использовать их в своих проектах не переделывая их снова и снова. ООП убирает барьеры и сложности в написании и управлении большими приложениями.
PHP позволяет нам писать приложения 2мя разными способами, первый — процедурный, а второй объектно ориентированный. Если вы до сих пор не поняли разницу между этими двумя подходами, давайте посмотрим на эти куски кода — один и тот же пример написанный разными подходами.
Процедурный:
А вот тот же кусок кода с использованием ООП:
Если внимательно посмотреть на эти 2 куска кода то можно заметить, что код с использованием ООП более читабельный и легче для восприятия.
Код с ООП организован лучше потому что в нём понятно какой объект чем обрабатывается. Большие приложения написанные на процедурном подходе становится практически не возможно воспринимать уже после выхода нескольких версий. Конечно вы можете следовать жёстким правилам написания программного кода, но они утверждены миллионами разработчиков которые знают что это не даст вам в конечном итоге управляемости и юзабилити проекта, если вы не используете в своей программе ООП.
Почти все большие приложения написаны с использованием Объектно ориентированного
подхода.
Исходя из изложенного выше, можно вынести преимущества использования ООП:
ООП был создан что бы облегчить жизнь разработчикам. Используя ООП вы можете разбить ваши большие проблемы на маленькие проблемы, которые решать гораздо проще.
Основное требование ООП: всё что вы хотите сделать — делайте объектами. Объекты это отдельная маленькая часть кода которая может объединять данные и свойства вместе. В приложениях все объекты взаимодействуют друг с другом.
ООП может быть рассмотрен лучше с разных сторон, особенно когда вам важно время разработки и последующее развитие приложения.
Основные преимущества использования ООП можно выразить как:
* Повторное использование: Объект это логический объект у которого есть комплект свойств и методов и он может взаимодействовать с другими объектами.. Объект может быть абсолютно независимым или может зависеть от других объектов. Объект обычно создают для решения специфических поставленных проблем. Следовательно когда другие разработчики сталкиваются с похожими проблемами, они могут подключить ваш класс к своему проекту и использовать его не боясь что он нарушит процесс их разработки. Это позволяет избежать DRY, что расшифровывается как Don’t Repeat Yourself ( не повторяйся). В процедурном или модульном программировании, повторное использование возможно только в совокупности.
* Рефакторинг: Когда вам необходимо в проекте использовать рефакторинг, ООП предоставляем вам максимум преимуществ, так как все объекты это маленькие элементы и содержат свои свойства и методы как часть себя. По этому использовать рефакторинг относительно легко.
* Расширяемость: Если вам необходимо расширять функциональность вашего проекта, вы можете достичь лучших результатов при помощи ООП. Одна из основных функциональностей ООП это расширяемость. Вы можете использовать рефакторинг объектов что бы добавить функциональность. Работая над этим, вы по прежнему можете сохранить
прежнюю совместимость объекта — следовательно вы можете прекрасно работать и с прежним кодом. Или же вы можете расширить объект и создать абсолютно новый, который будет содержать все необходимые свойства и методы родительского объекта от которого происходит новый, а потом уже добавить в него новые функции. Это называется “наследование” и это очень важная возможность ООП.
* Поддержка: объектно-ориентированный код легче поддерживать так как
он следует весьма жёстким соглашениям написания кода и пишется в самопоясняющейся форме.
К примеру, когда разработчик дополняет, перерабатывает код, или отлаживает его, он может легко найти внутреннюю структуру кода и поддерживать код время от времени. Более того, когда в вашем окружении работает команда разработчиков ООП может быть лучшим решением так как вы можете распределять ваш код между членами команды, после разбития его на маленькие части. Эти маленькие части могут быть разработаны как отдельные объекты, следовательно разработчики могут работать практически независимо друг от друга. В конечном итоге объеденить все части в одно приложение не составит большого труда.
* Эффективность: Идея ООП в действительности была разработана для повышения эффективности и облегчения процесса разработки. Несколько шаблонов проектирования разработаны что бы создавать более эффективный и хороший код.
Более того в ООП вы можете вы можете размышлять над вашими решениями в более удобной форме чем в процедурном подходе. Поскольку вы разбиваете вашу проблему на несколько маленьких проблем и вы находите решение для каждой из них отдельно, большая проблема решается сама по себе.
Авторский перевод из книги Object Oriented Programming with PHP5
P.S мой первый хабратопик, если понравится буду переводить книгу дальше, как по мне довольно интересная и содержательная
Зачем нужен ООП?
p.s. на пхп и питоне кстате тоже можно писать в декларативном стиле, если не ошибаюсь. 😉
Не везде и не всегда нужны классы. Вы верно заметили. НО! Прежде чем принять решение о том, что в конкретном месте кода класс только вредит, нужен профайлер или другие инструменты позволяющие принять такое решение. К примеру в Python словарь значительно выигрывает по скорости чем класс с методами.
Фишка ООП в том, что человек уже думает классами! Поднимаем голову к небу и видим «Птица летит», другими словами «У объекта «Птица» был вызван метод «Лететь»», но мы так сложно не думаем и для нас это просто «Летящая птица».
Вспомните детство и моменты когда родители посылали за хлебом. Как это происходило? Возможно это было так: «Объект сын в твое поле ложу объект «Задача» с полями «хлеб», «комод» и «100 рублей», в поле «результат» ложу «Хлеб». Объект сын вызываю метод «Купить»». Не думаю что это было так, мне кажется это было так: «Сын возьми 100 рублей и купи хлеба». В неявном виде обратились к объекту «Сын», вызвали метод «Взять» и передали аргумент «100 рублей» и ожидаем результат вызова в виде значения «Хлеб».
Попробуйте процедурный подход переложить в нашу естественную жизнь? 😉 Попробуйте так общаться, процедурно. Это очень сложно. Потому что человек привык думать объектами! Самолет, кошка, лошадь, дерево и др. Для нас вроде есть концепция «кошка», но конкретная кошка «Масяня» сильно отличается от другой конкретной кошки «Машка».
Изучая задачу мы прежде всего должны задать вопрос : «Что является условием завершения задачи?» и вторым не менее важным «Что используется при достижении результата?». Вот это «что используется» как правило и есть объекты.
«Объект сын в твое поле ложу объект «Задача» с полями «хлеб», «комод» и «100 рублей», в поле «результат» ложу «Хлеб». (с)
Вы к сожалению усложняете и запутываете человека.
Понимание ООП лучше начинать совсем с других вещей. Меня вымораживают эти оторванные от реальности уроки типа звери, звери бегают, цветные звери бегают, цветные звери в зоопарке бегают.
Я бы посоветовал человеку начинать с инкапсуляции. Как сам начинал 🙂 Просто сбор функций, работающих с одной сущностью, под одной крышей.
Потом уже придет наследование и прочие радости.
Arris: Какой нафиг инкапсуляция? 😉 Человек начнет ее понимать и получать пользу от ее применения только когда начнет «кожей ощущать» что такое объект.
>>Просто сбор функций, работающих с одной сущностью, под одной крышей.
Если бы я такое сказал на собеседовании, то на все 100% уверен меня бы на работу не взяли!
Вся суть ООП в том, что программист «моделирует». Какой нафиг набор функций? Надо мыслить объектами. Подход «набор функций» даже в процедурном программировании никогда не применялся. Там применяется алгоритм «Эта функция решает задачу?», «Если нет, давайте раздробим на подзадачи», «Достаточно ли мы декомпозировали задачу на подзадачи чтобы ее решить?». Даже в процеудурном стиле не думают и не мыслят «просто сбор функций». Тапком по голове ;)))
Дмитрий: я наверное плохо сформулировал свою мысль. но я понимал так:
Вот у меня есть самописная CMS. Вот у меня есть куча функций, контент из базы собирающих (model типа), а вот есть куча функций, контент оформляющих для вывода (типа view).
Вот есть один вариант конечного представления, а вот другой. Model один и тот же везде, а view в частично перекрываются.
понятно, названия совершенно условны 🙂
а не «printAuthorsListFromDBforBootstrapTemplate( мульон параметров )»
Но наверное это еще не ооп 🙂
ООП в PHP где нужен? [закрыт]
Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы на него можно было дать ответ, основанный на фактах и цитатах.
6 ответов 6
Приведу пример, с которым сегодня столкнулся. Я писал на основе фреймворка Yii небольшой аналитический модуль, которому на вход подаются одни данные, он их анализирует, и выдает другие. Все было хорошо, когда анализировать нужно было только одного типа данные, Я просто все в одном контроллере написал, и оно отлично работало.
Сегодня шеф сказал, что нужно к этой аналитике прикрутить возможность анализировать данные, для которых входящий набор параметров будет отличаться, т.к. анализировать данные нужно из другого региона.
А для манипуляции данными, ООП тоже удобно очень тоже.
Теперь вам нужно сделать складной стол. Вам приходится копировать представленный выше массив, и добавлять в него новые параметры и методы:
Кроме того, до появления замыканий нельзя было элегантно было использовать анонимные функции в качестве значений ключей в ассоциативных массивах.
Теперь представьте, вам необходимо создать 5 экземпляров столов. Да, используя массивы это решается обычным присваиванием:
Ясно и просто, но не очень красиво. Давайте теперь добавим метод складывания стола в массив:
Вызовим его теперь:
некрасиво как-то. А еще мы не можем указать явно, какой аргумент передается в функцию. Можно использовать array, но в таком случае будут пропущены в обработку все структуры, являющиеся массивами. Нет контроля типов данных.
Давайте теперь сделаем все это, используя ООП:
Создаем складной стол:
Теперь сложим стол:
Простите за сумбурность.
Конечно не нужно, зачем всегда удобнее использовать 100 переменных, которые между собой не как не связаны
Еще 3 недели назад я бы тоже мог задать такой же вопрос тут.
За эти 3 недели я увидел некоторые плюсы:
Методы (Функции) можно структурировать в класс Если у тебя раньше был набор функций для работы со строкой, то сейчас объедени его в класс.
Это может позволить тебе делать такие конструкции:
Из функции (метода) можно делать не просто «return true», но и возвращать кое какую инфу Пример
print ‘Да, это массив’;
print ‘Жаль, но это ‘.$e->getRealType();
За 3 недели больше плюсов не увидел. А как утверждают, то в ООП есть и более вкусные вещи.
Моя личная рекомендация: Только после написания кода я смог сделать какие то вывод об ООП. Все что было в теории, это только разговоры. Если лень читать (как мне), то просто посмотри видео про ООП. Лично после просмотра, я начал писать с нуля какие то задачки, чтобы понять ООП на практике.
После 3х недель освоения, я знаю все же мало, поэтому я по совету старшего Khvorostin буду читать книгу (кому надо ссыль на кинигу).
Просто начни практику и почувствуешь новые возможности PHP.
Объекты нужны не PHP, а разработчикам. И нужны они для того, чтобы проще модифицировать код. Дело в том, что как только программа перестаёт помещаться целиком в мускулистом мозгу программиста, ему приходится переключаться между разными частями программы, снова и снова понимать уже написанный код. При таком переключении очень легко запутаться даже в собственном коде. Всё становится ещё хуже, если над проектом работают несколько разработчиков, а часть кода была написана 2 года назад.
ООП позволяет организовать программу в виде изолированных, относительно независимых частей, сокращая объём того, что необходимо держать в уме.
Кстати, большинству функций mysqli_ нужна ссылка на подключение к базе данных. Представим теперь, что в каком-то проекте две базы данных, и они не просто называются по разному, они даже находятся на разных серверах. Тогда префикса mysqli_ окажется недостаточно, чтобы понимать с чем же мы имеем дело сейчас. Придётся запомнить как называется подключение к одному серверу, как к другому, какое уже инициализировано, какое только предстоит установить. Вот небольшая иллюстрация:
Обратите внимание на суффиксы 1 и 2, это естественная попытка разделить переменные на относящиеся к одному объекту и к другому. Эти объекты существуют прежде всего в уме разработчика, но средства ООП помогают выразить в коде эти мысли более ясно.
Итак, объекты нужны чтобы упростить жизнь разработчикам и помочь им писать большие и сложные системы. Освоив ООП, вы сможете освободить свой могучий разум от рутинного запоминания, где и как всё устроенно в вашей программе, и использовать его для чего-то по-настоящему крутого!
Стоит ли использовать ООП в PHP?
существует много споров о том, является ли объектно-ориентированное программирование хорошим или нет. Но использование ООП в Php медленнее. Было бы хорошей торговлей использовать процедурное программирование и более быструю скорость и ООП с более медленной скоростью (поскольку классы должны инициироваться каждый раз, когда загружается страница, и большие веб-сайты начнут замедляться).
Что еще более важно, было бы хорошо обернуть материал внутри класса и использовать статические функции или было бы лучше просто иметь много лежащих функций с префикс ex: wp_function().
9 ответов
да, почти всегда хорошая идея использовать ООП. Это связано с тем, что ООП-это стиль кодирования, а стили кодирования по большей части легко переносятся через языки.
люди не используют стили кодирования, потому что они используют определенный язык. Люди используют стили кодирования, потому что стиль кодирования предлагает хорошие методы, чтобы делать то, что они считают желательным. Поэтому, пока существуют базовые элементы (наследование, свойства класса и т. д.), Он всегда будет можно писать в таком стиле.
нет, использование процедурных функций для доступа к ним, вероятно, не является хорошей идеей. Это потому, что вам, вероятно, придется сделать что-то подобное, чтобы сохранить состояние.
это плохая идея, поскольку она создает тонну глобального состояния.
Что касается статических функций, это выбор дизайна, но я бы ошибся, избегая классов, полностью состоящих из статических функций. На самом деле нет никакого преимущества над префиксами, и использование конструкции просто потому что это плохая идея.
те же аргументы о производительности были сделаны о Objective C и C++ в день. И ответ на эту проблему состоял в том, чтобы воспользоваться доступной памятью и вычислительной мощностью, которая постоянно становится больше, лучше и быстрее.
Это, однако, хорошая вещь, чтобы быть обеспокоены о производительности программного обеспечения. Однако, глядя под капот процедурных и ОО как место, чтобы начать это немного заблуждение. Для начала вам нужно сосредоточиться на написании эффективного кода, будь то процедурный или OO (и оба они актуальны).
имейте в виду, что, хотя PHP не может быть самой быстрой платформой (Java, например, пинает ее прикладом), PHP используется для питания некоторых из самых тяжелых веб-сайтов в Интернете: а именно Facebook.
Если у вас есть какие-либо другие сомнения в PHP и OO, просто посмотрите на Zend и Magento (на основе Zend). Magento является очень ресурсоемкая платформа, использование памяти может быть выше 36 Мб на экземпляр. Однако сама платформа способна обрабатывать миллионы просмотров. Это связано с тем, что правильно настроенная серверная среда со здоровой подачей аппаратных ресурсов делает все преимущества использования OO намного превосходящими стоимость самого сервера. Но в мире кластерных компьютеров, не использующих обработку сила и память (ответственно) доступны вам-ИМХО-клиническое безумие.
по моему скромному мнению, разработчики PHP не должны пытаться идти исключительно одном направлении. (процедурный vs объектно-ориентированный) в некоторых случаях все, что вам нужно, это несколько глобальных функций, в других случаях более выгодно использовать объекты. Не пытайтесь заставить все так или иначе, будьте гибкими и используйте то, что лучше всего подходит для каждой ситуации.
Я категорически не согласен с ответом Chacha102.
правильный ответ на этот вопрос заполнит несколько книг-не говоря уже о 20-строчном сообщении здесь.
оба подхода имеют свои преимущества и недостатки. Я бы рекомендовал всем, кто хочет считать себя хорошим программистом, иметь значительный опыт в процедурном, не процедурном и объектно-ориентированном программировании. А также опыт работы с различными методологиями, такими как SCRUM, cascade и РАДИАН.
Что касается пригодности PHPs для OO против процедурного кодирования, конечно, корни языка находятся в последнем (но обратите внимание, что Java и ASP являются гибридными, а не истинными языками OO).
утверждать, что вы всегда должны писать процедурный код, потому что он будет работать быстрее, чем код ОО:
1) не обязательно верно 2) полностью игнорирует относительную стоимость времени разработчика против аппаратных затрат
было бы хорошо обернуть материал внутри класса и использовать статические функции
учитывая, что пространства имен теперь доступны в PHP, это действительно грязный способ избежать конфликтов пространств имен, а не то, что я бы рекомендовал.
ООП имеет больше достоинств, чем его заслуги. см. PHP OOP, каковы преимущества?. Также смотрите для ООП против PP в PHP.
на самом деле нет идеального ответа, поскольку он зависит от стольких неизвестных переменных, и тогда он не должен быть «все или ничего».
например, если вы разделите свое приложение на модель MVC, у вас может быть модель OO, но держите контроллер более упрощенно процедурным.
вы можете использовать классы как средство просто группировать общие статические функции, или вы можете взять его намного дальше в шаблон активной записи.
Если вы строите небольшая одностраничная веб-форма, которая снимает сообщение по электронной почте, вам действительно не нужен OO-чтобы вы, возможно, включили существующий почтовый класс для использования.
никто не может дать вам правильный совет, не понимая проект, который вы берете на себя.
Что сказал, Если ваша единственная забота скорость, то ОО будет быть немного медленнее. И есть много подлых вещей, которые вы можете сделать даже в процедурном PHP, чтобы имитировать некоторые из выигрышей OO. Но если вы не принимаете на себя огромный проект, дополнительное время никогда не будет много. И к тому времени, когда у вас будет огромный проект, плюсы OO могут перевесить минусы его накладных расходов.
да по мере роста вашего приложения.. (и это будет) это избавит вас от многих часов разочарования. И повторяя себя (копируя код вставки повсюду).. 🙂
мне было любопытно об этом сам. К сожалению, после того, как я изменил свой код с процедурного на ООП, я запустил некоторые тесты, а не заранее.
вот контрольный код.
результаты ООП колебались между 0,13 и 0,2 секунды;
процедурные результаты колебались между 0.08 и 0.1 секундами.
результат оставался неизменным в течение длительного времени.
Я призываю вас, чтобы построить свои собственные тесты.