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

Ответ 1

Во многих сценариях процедурное программирование просто отлично. Использование OO для его использования бесполезно, особенно если вы просто закончите с POD (обычные старые данные).

Сила 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, либо реализовать interface.

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

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

Ответ 2

Использование подхода объектно-ориентированного программирования, а не процедурного подхода к программированию в программе на самом деле не зависит от языка (будь то 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, они могут иметь общую функциональность.

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

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

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

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

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

Ответ 8

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

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

Ответ 9

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