Зачем использовать PHP ООП над основными функциями и когда?

использование объектно-ориентированного подхода к программированию, а не процедурного подхода к программированию в программе На самом деле не зависит от языка (будь то PHP или нет), а от типа проблемы, которую вы пытаетесь решить.

(Я просто собираюсь использовать псевдокод в своих примерах, поскольку я не слишком хорошо знаком с PHP.)

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

perform_truncation(my_string, 10)
to_upper(my_string)
perform_magic(my_string, hat, rabbit)

однако, если вы собираетесь иметь дело со многими различными элементами (такими как файлы или любое другое представление, Ну, объектов), то объектно-ориентированный подход будет лучше.

например, если у вас была куча CarS и хотел, чтобы они drive, то в процедурном, вы можете сделать что-то по линии:

drive_car(first_car)
drive_car(second_car)

где, как, в ООП, в Car поездка сам по себе:

RedCar myRedCar();
BlueCar myBlueCar();

myRedCar.drive();
myBlueCar.drive();

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

это действительно сводится к типу проблемы, которая делает любой процедурный подход лучше, чем объектно-ориентированный, и наоборот.

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

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

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

Я постараюсь сохранить свой ответ в качестве дополнения, потому что ответы Majd Taby и Coobird действительно хороши.

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

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

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

все они имеют одинаковые имена поведения, такие как print (), update () и т. д...но путем инкапсуляции их в виде объектов и изменения реализаций методов в классы я могу сделать свой код во время выполнения очень простым и чистым по всему сайту. Кроме того, и это было ключевым, несмотря на то, что у меня было разное поведение, я мог работать с разными объектами использование одного и того же метода вызывает во всем приложении. Это позволяет второму разработчику работать над фактической реализацией, в то время как я работаю над более глубоким кодом.

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

допустим, у меня есть большой файл с 50 функции, почему я хочу позвонить это в классе? и не имя функции.)( Должен ли я переключиться и создать объект, который содержит все мои функции?

перемещение в ООП не должно рассматриваться как простой "переключатель", как вы описали выше.

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

это действительно включает в себя сделать шаг назад и узнать о концепциях позади ООП, но окупаемость будет хорошо стоит говорить как кто-то, кто прошел через этот процесс в дни до www.

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

Как только вы действительно поймете ООП, вы ответите на свой собственный вопрос.

Если у вас есть 50 функций вместо 50 статических методов в классе Utilities, вы "загрязняете" глобальное пространство имен.

используя класс с 50 статическими методами, имена методов являются локальными для вашего класса.

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

ООП позволяет создавать структурированные контейнеры кода, называемые классами, которые могут быть родителями/детьми друг друга. Это может помочь в создании приложения, поскольку его легче поддерживать и может, если это сделано правильно, уменьшить избыточность кода. ООП добавляет немного накладных расходов, но это не очень заметно и перевешивается недостижимостью процедурного кода. Если вы пишете большое приложение, def go OO, особенно если над ним будут работать многие люди.

например, если вы разрабатываете простой сайт. Вы можете создать объект страницы. Объект page отвечает за переход в базу данных и получение различных настроек для страницы, таких как метаданные, теги заголовков или даже количество определенных "компонентов" на странице и их тип (например, элемент управления календарем, виджет и т. д.).

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

теперь есть другие способы сделать это процедурно, например, с помощью includes. Тем не менее, вы обнаружите, что делаете меньше ошибок и ошибок. Например, можно определить абстрактный метод в классе страницы. Это означает, что этот метод должен быть определен в любом объекте, который его расширяет. Скажем, вы создали функцию setPageAttributes() как абстрактную в своем классе страниц. При этом вы создаете пустую функцию. Когда вы создаете свой класс, вы Чтобы создать функцию setPageAttributes () (с намерением заполнить ее, например, получить доступ к переменным, определенным в классе страницы, и использовать ее для установки фактических элементов на странице, шаблоне или представлении, которые вы используете), или вы получаете ошибку PHP.

Если вы работаете с другими людьми, чтобы написать свой проект, абстрактные методы скажут человеку:"Эй, вам нужно определить эти функции в любом коде, который вы пишете". Это заставило приложение быть последовательный.

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

использование ООП дает вам следующее преимущество:

1. структурированность
2. возможность повторного использования
3. Простота Обслуживания
4. инкапсуляция данных

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

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

для получения подробной информации о преимуществах вы можете прочитать мой пост на ООП в PHP

принятый ответ, похоже, забыл указать, что можно вызывать функции на основе имени переменной, например, в Примере herew:

function drive($the_car){
    $the_car();
}

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

---

дополнительные переменные могут быть легко предоставлены как таковые:

function operate($the_car,$action){
    $the_car($action);
}

function ferrari($action){
    switch($action){
        case 'drive':
            echo 'Driving';
            break;

        case 'stop':
            echo 'Stopped';
            break;

        default: return;
    }
}


operate('ferrari','drive');

здесь есть оператор switch, но он должен поставлять дополнительные функциональность, которая не была в исходном примере, так что это ни в коем случае не противоречие.

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