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

Question

Есть несколько сообщений по этому вопросу, но я не совсем понял, когда использовать объектно-ориентированное кодирование и когда использовать программные функции во включении. Кто-то также упомянул мне, что ООП очень тяжёл в работе и увеличивает нагрузку. Это правильно?

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

Answer 1

В большинстве случаев процедурное программирование просто отлично. Использование ОО ради его использования бесполезно, особенно если вы просто собираетесь получить POD объектов (plain-old-data).

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

Одно из самых приятных мест IMO, в котором светится OO, - это возможность избавиться от кода включения. Рассмотрим:

function drive($the_car){

    switch($the_car){

      case 'ferrari':
          $all_cars->run_ferrari_code();
          break;

      case 'mazerati':
          $all_cars->run_mazerati_code();
          break;

      case 'bentley':
          $all_cars->run_bentley_code();
          break;
    }
}

с альтернативой OO:

function drive($the_car){

    $the_car->drive();
}

Полиморфизм позволит осуществлять правильный тип «вождения», основываясь на информации времени выполнения.

---

Заметки о полиморфизме:

Второй пример здесь имеет несколько предпосылок: все классы автомобилей либо расширят класс abstract , либо реализуют интерфейс .

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

Так что, пока вы убедитесь, что все ваши конкретные машины либо расширяют абстрактный класс car, либо реализуют интерфейс, такой как canBeDriven (оба из которых должны объявлять метод drive()) Вы можете просто вызвать метод drive() для объекта, который, как вы знаете, является автомобилем (но не типом автомобиля), не опасаясь, что он не будет определен, так как PHP выдаст вам фатальные ошибки, пока вы не определите эти методы в своем конкретном случае. авто классы.

Answer 2

Я постараюсь сохранить свой ответ в качестве дополнения, потому что ответы Маджда Таби и Кобирда действительно хороши.

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

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

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

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

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

Answer 3

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

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

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

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

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

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

drive_car(first_car)
drive_car(second_car)

Где, как в ООП, Car может управлять собой:

RedCar myRedCar();
BlueCar myBlueCar();

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

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

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

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

Теперь есть другие способы сделать это процедурно, например, с помощью включений. Однако вы обнаружите, что делаете меньше ошибок и ошибок. Например, вы можете определить абстрактный метод в своем классе Page. Это означает, что этот метод ДОЛЖЕН быть определен в любом объекте, который его расширяет. Допустим, вы создали функцию setPageAttributes () как абстрактную в своем классе Page. Когда вы делаете это, вы создаете пустую функцию. Когда вы создаете свой индексный класс, вы ДОЛЖНЫ создать функцию setPageAttributes () (с намерением заполнить ее, например, получить доступ к переменным, определенным в классе Page и использовать его для установки фактических элементов на странице, шаблона или просмотра вы используете) или вы получите ошибку PHP.

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

Answer 10

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

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, но он предоставляет дополнительные функциональные возможности, которых не было в первоначальном примере, поэтому это ни в коем случае не противоречие.