Есть несколько сообщений по этому вопросу, но я не понял, когда использовать объектно-ориентированное кодирование и когда использовать программные функции в include. Кто-то также упомянул мне, что ООП очень тяжело работать и делает больше рабочей нагрузки. Это правильно?
Предположим, у меня большой файл с 50 функциями. Почему я хочу назвать их в классе? А не по function_name ()? Должен ли я переключаться и создавать объект, который содержит все мои функции? Каким будет преимущество или конкретная разница? Какие преимущества он приносит для кода ООП в PHP? Модульность?
Во многих сценариях процедурное программирование просто прекрасное. Использование 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(); }
Полиморфизм позволит обеспечить надлежащий тип «вождения», основанный на информации о времени выполнения.
Заметки о полиморфизме:
Второй пример здесь имеет некоторые посылки: все классы автомобилей будут либо расширять абстрактный класс, либо реализовать интерфейс .
Оба позволяют принудительно расширять или внедрять классы для определения конкретной функции, такой как drive() . Это очень мощно, так как позволяет вам drive() все автомобили, не зная, какой из них вы ведете; это потому, что они расширяют абстрактный класс, содержащий метод drive() или реализуют интерфейс, заставляющий метод drive() быть определенным.
Поэтому, пока вы убедитесь, что все ваши конкретные автомобили либо расширяют автомобиль абстрактного класса, либо реализуют интерфейс, такой как canBeDriven (оба из которых должны объявить метод drive() ), вы можете просто вызвать метод drive() для объекта, который вы знаете, что это автомобиль (но не какой тип автомобиля), не опасаясь, что он не будет определен, поскольку PHP будет генерировать фатальные ошибки, пока вы не определите эти методы в ваших конкретных классах автомобилей.
Использование объектно-ориентированного подхода к программированию, а не процедурного программирования в программе, на самом деле не зависит от языка (будь то 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 которые могут иметь общие функциональные возможности.
Это действительно сводится к типу проблемы, которая делает либо процедурный подход лучше, чем объектно-ориентированным, и наоборот.
Помимо проблемы процедурного или объектно-ориентированного, это может быть своего рода «запах кода», чтобы иметь один исходный файл со многими функциями. Это также можно сказать о классах, которые содержат много функциональных возможностей, которые могут лучше выполняться как отдельные функции в отдельных классах.
Проблема здесь может заключаться в организации кода, а не в выборе процедурного или объектно-ориентированного программирования. Организация функций в отдельные исходные файлы может быть тем, что здесь необходимо, чем отказаться от процедурного подхода к написанию программы.
В конце концов, есть много программ, написанных в процедурном программировании, который хорошо написан и прост в обслуживании.
Я постараюсь сохранить свой ответ в качестве дополнения, потому что ответы Маджда Таби и Кообарда действительно хороши.
В течение нескольких лет я был главным программистом-программистом и не боролся с программированием ООП, но на самом деле не видел много актуальности … до тех пор, пока я не начал работать над командой и не строил более важные и сложные проекты.
ООП действительно сияет, на мой взгляд, когда вам нужно писать скудный, легко ремонтируемый код для более сложных приложений. И помните о вас, не в любой ситуации, но есть некоторые, где процедурные просто не будут работать так хорошо.
Большинство моих примеров больших реализаций ООП – это проекты, в которых у меня было несколько вещей, которые были связаны друг с другом, но все они немного отличались. Сайты с большим количеством форм, множество пользователей, множество продуктов и т. Д.
Все они имеют похожие имена поведения, такие как print (), update () и т. Д. … но, инкапсулируя их как объекты и изменяя реализации методов в классах, я могу сделать свой код во время выполнения очень простым и чистым на всем сайте. Кроме того, и это было ключевым, несмотря на то, что у меня было другое поведение, я мог работать с разными объектами, используя одни и те же вызовы методов во всем приложении . Это позволяет второму разработчику работать над фактической реализацией, когда я работаю над более глубоким кодом.
Я не знаю, помогает ли это кому-либо, но, будучи человеком, который был в вашей ситуации не так давно, я люблю ООП.
Допустим, у меня большой файл с 50 функциями, почему я хочу назвать их в классе? а не по функции_имя (). Должен ли я переключаться и создавать объект, который содержит все мои функции?
Переход к ООП не должен рассматриваться как простой «переключатель» в том, как вы описываете выше.
ООП требует совершенно иного способа мышления о программировании, которое включает в себя переделку вашего мозга. Поскольку перемотка мозга не происходит в одночасье, многие люди не желают подвергать себя требуемому процессу перемотки. К сожалению, переделка потребует инвестиций во времени и усилий: исследования, учебные пособия, проб и ошибок.
Это действительно связано с тем, чтобы сделать шаг назад и узнать о концепциях ООП, но окупаемость будет стоить того, чтобы он выступал как кто-то, кто прошел этот процесс в преддверии www дней.
После того, как вы его получите »и следуйте рекомендациям ООП в повседневной жизни, вы расскажете другим, как изменилась ваша жизнь программирования в лучшую сторону.
Когда вы действительно поймете ООП, вы ответите на свой вопрос.
Если у вас есть 50 функций вместо 50 статических методов в классе Utilities, вы «загрязняете» глобальное пространство имен.
Используя класс с 50 статическими методами, имена методов являются локальными для вашего класса.
Я не могу сказать, какой из них лучше. но по моему опыту вы можете улучшить управление кодом с помощью ООП. вы знаете, какой код есть где, какая функциональность определена в каком файле и т. д. о служебных ресурсах во время выполнения для ООП Я где-то читал (и, я думаю, это правда), что если вы пишете плохой код в классических функциях и тот же самый плохой код в ООП функциональная версия работает лучше. поэтому, если ваш код не написан плохо, нет никаких доказательств того, что ООП замедляет ваше приложение. также помните, что эти «медленные» и «накладные» вещи измеряются в миллисекундах. поэтому, если ваше приложение не обслуживает множество пользователей (например, более 100 пользователей в минуту), вы можете не почувствовать никакой разницы.
ООП позволяет создавать структурированные контейнеры кода, называемые классами, которые могут быть родителями / детьми друг друга. Это может помочь в создании приложения, поскольку его легче поддерживать и может, если это сделать, должным образом уменьшить избыточность кода. ООП добавляет немного накладных расходов, но это не очень заметно и перевешивается неподдерживаемостью процедурного кода. Если вы пишете большое приложение, откройте OO, особенно если он будет работать многими людьми.
Например, скажем, вы разрабатываете простой веб-сайт. Вы можете создать объект Page. Объект страницы отвечает за переход в базу данных и получение различных параметров страницы, таких как метаданные, теги заголовков или даже количество определенных «компонентов» на странице и их тип (например, элемент управления календарем, виджет , и т.д).
Затем вы можете создать другой класс, например Index, который расширяет страницу. Индекс будет индексом или главной страницей. Если у вас есть каталог продуктов, у вас может быть страница расширения класса Catalog. Поскольку как ваш раздел каталога, так и ваша домашняя страница должны получить данные из базы данных о метаданных страницы и базовой конструкции страницы, вам понадобится 1 объект, который вам уже помогает. В обеих этих ситуациях страница выполняет всю работу и получает данные страницы из базы данных, загружает ее в переменные, которые затем доступны как в вашем классе индекса, так и в вашем классе каталога. Вам не нужно писать код, чтобы войти в базу данных и получить его снова на каждой странице, которую вы пишете.
Теперь есть другие способы сделать это процедурно, например, с включенными. Однако вы обнаружите, что делаете меньше ошибок и ошибок. Например, вы можете определить абстрактный метод в своем классе страницы. Это означает, что этот метод ДОЛЖЕН быть определен в любом объекте, который его расширяет. Поэтому скажите, что вы создали функцию setPageAttributes () как абстрактную в своем классе страницы. Когда вы это сделаете, вы создадите пустую функцию. Когда вы создаете свой индексный класс, вы должны создать функцию setPageAttributes () (с намерением заполнить его, например, получить доступ к переменным, определенным в классе страницы, и использовать его для установки фактических элементов на странице, шаблоне или вы используете), или вы получаете ошибку PHP.
Если вы работаете с другими людьми, чтобы получить свой проект, абстрактные методы подскажут человеку: «Эй, вам нужно определить эти функции в любом коде, который вы пишете». Это заставило приложение быть последовательным.
Наконец, вы не можете перейти в рамки, такие как форматы MVC, если вы не делаете ООП. Хотя нет необходимости идти в MVC, и есть некоторые дебаты, он выделяет все компоненты приложения и необходим в средах, где многие люди (дизайнеры, кодеры, сотрудники маркетинга) работают над одним и тем же кодом.
В принятом ответе, как представляется, пренебрегают утверждением, что можно вызвать функции, основанные на имени переменной, например, в данном примере:
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, но он должен предоставить дополнительную функциональность, которая не была в оригинальном примере, поэтому это никак не противоречит.
Концепция ООП используется в PHP, чтобы обеспечить код. Поскольку все запросы записываются в файл функции вместо файла кода, поэтому никто не может легко взломать наш код. Поэтому лучше использовать классы в PHP вместо прямого написания запросов.