Насколько важны классы? (PHP)

Я не знаю много о классах, но имею разумные знания PHP / MySQL. Но почему я должен изучать занятия? Я знаю, что они важны, но какие преимущества я могу увидеть, используя их, с которыми я не могу?

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

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

Фон Php очень функциональный, огромная часть предоставляемого языка – это функции, и иногда квадратный привязку объектов не вписывается в круглое отверстие php.

Это, конечно же, не относится к Java, но фон php очень укоренен в функциях.

Редактировать:

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

Я бы сказал, есть несколько способов написать PHP-код:

  1. Плохой процедурный код (малое повторное использование, возможно, использует функции, но не очень хорошо, возможно, использует объекты, но не очень хорошо).
  2. Хороший функциональный код (максимизированное повторное использование, минимизация сложностей состояния, разделение проблем)
  3. Плохой объектно-ориентированный код (большие многогранные объекты, сложные иерархии и т. Д.)
  4. Хороший объектно-ориентированный код (объекты конкретной задачи, четкое разделение таких проблем, как MVC)

И в конечном итоге, поскольку php 5.3 созревает, мы сможем начать металирование более функционального программирования в категорию «хороший функциональный код», и это станет еще более эффективной альтернативой. Тем временем, хотя, получите удобство с 2 и 4, потому что вам понадобится их обоих.

Инкапсуляция для одного.

Стив Джобс однажды использовал хорошую аналогию (это было в интервью). Перефразируя память, он сказал:

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

Кроме того, я нашел интервью . Интересное чтение.

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

$files = new FilesInFolder('your/path'); $files->getByExtension('*.jpg'); 

Вам все равно, использует ли он glob() или readdir() .

Обновить

В отличие от файла, полного глобальных функций, таких как functions.php : вы можете сгруппировать все функции в определенные инструменты. Например, в приведенном выше примере вы могли бы иметь getFiles() и filterFilesByExtension() но эти две связанные функции будут находиться в глобальной области, не говоря уже о том, что второй потребует передать файлы в виде массива.

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

Многие люди на подобной странице утверждают, что a) OOP – единственный хороший способ писать программы и b) он отчаянно необходим для любой программы и / или домашней страницы. Я думаю, если вы думаете о том, что пишете в качестве домашней страницы, вам, вероятно, не нужен ООП, если только это не очень большая домашняя страница.

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

Если вы считаете, что PHP, который вы пишете, трудно справиться, изучение ООП, вероятно, хорошая идея, даже если вы только получаете практику. Возможно, вы даже захотите попробовать его на другом языке, например, Java или Ruby. Наверное, легче найти хорошие книги об ООП на этих языках.

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

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

Обновить:

Кроме того, возможно, стоит взглянуть на это и отметить, что в Википедии есть раздел в классе (компьютерная наука) под названием « Причины использования классов, которые демонстрируют несколько ключевых моментов для использования классов».

Кроме того, из ваших предыдущих вопросов кажется, что вы много работаете с PHP и MySQL. Чтобы продемонстрировать полезные классы, вы можете создать класс Connection который обрабатывает соединение с вашей базой данных MySQL, поэтому любые изменения, внесенные в базу данных, которую вы можете редактировать в одном месте ( ваш класс Connection ), вместо того, чтобы находить все строки кода, когда это называется.

Классы и объекты в PHP делают очень важный аспект программирования намного проще: абстракция.

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

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

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

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

Как всегда, что вам нужно сделать, объектно-ориентированный способ может стать полезным по многим причинам:

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