Зачем использовать классы в php? - PullRequest
5 голосов
/ 02 февраля 2011

Я хочу знать, почему мы используем классы в php. Я видел во всех открытых источниках они используют классы для выполнения запроса. Это означает, что они используют классы для получения результатов, вставки запроса и т. Д. Я думаю, что это используется для согласованности и ускорения, но, насколько мне известно, если мы выполним запрос с использованием mysql_query(), а не создадим ссылку на объект $db->query, он будет выполняться быстрее по сравнению на второй, потому что в объекте он перейдет к функции, а затем выполнит ее там и после этого вернет результат, но в случае mysql_query() он выполнит запрос в том же месте. Поэтому я думаю, mysql_query() будет выполняться быстро. Итак, почему мы используем классы и объект для выполнения запроса, каковы преимущества использования классов?

Ответы [ 5 ]

12 голосов
/ 02 февраля 2011

Инкапсуляция: класс - это полезный пакет, содержащий код и соответствующие данные вместе, изолированный от всего остального.Это облегчает его перемещение без поиска точных переменных, без коллизий с существующим кодом / данными.

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

РЕДАКТИРОВАТЬ: я был возражен с аргументом "наследование является более мощным, чем инкапсуляция".Я думаю, что это не относится к сценариям и веб-сценариям, и я попытаюсь объяснить, почему:

Первый , время жизни веб-страницы - это пара запрос / ответ и в идеале меньше секунды.Состояние обычно сохраняется во внешних объектах (сеанс, куки, БД и т. Д.).Поскольку время жизни страницы очень короткое, возможные состояния в коде веб-страницы меньше, чем, скажем, у толстого клиента.Это почти всегда небольшие пакеты кода, выполняемые и непрерывно завершающие работу.Возможно, веб-страница сопоставима с консольным приложением с точки зрения простоты и количества параметров дизайна.Хотя количество входных параметров в форме может составлять гигабайты, связь между элементами пользовательского интерфейса и входными параметрами ограничена разрешением экрана, общей возможностью пользователя к тому, что он / она может заполнить за один раз.Поэтому в большинстве случаев мы имеем небольшое количество входных параметров, что означает меньшее количество состояний.Конечно, в комбинаторном и «изменчивом» мире это не так, но в случае «типичных веб-приложений» внутреннее состояние также невелико, поэтому мое утверждение правдоподобно.

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

Доступ к данным также осуществляется существующими библиотеками и предметами роскоши, такими как «наследование» или «полиморфизм»там бесполезно.Вы все еще можете использовать классы, но это будет просто инкапсуляция.Вы не можете наследовать / повторно использовать код MySQL для написания кода T-SQL или PL / SQL.Вам нужна полная замена.О, может быть, ваш SELECT * FROM table мог бы быть "унаследован" и думать о возможностях, вау.

Теперь, что мы оставили?Да, бизнес-логика.Мы уже упоминали, что бизнес-логика также является короткими очередями обработки информации.В самом PHP-коде нет постоянного бизнес-состояния.Мы знаем, что почти все бизнес-операции должны занимать меньше секунды из-за требований Интернета.Поэтому состояния, которые вы можете пройти, опять же, намного меньше, чем полноценное приложение.У вас есть элементарные изолированные бизнес-операции, выполняемые для большинства случаев в типичном веб-приложении .

Теперь вернемся к дизайну.Мы знаем, что наша страница состоит из следующих частей:

  • Вход
  • Бизнес-логика
    • Доступ к данным
  • Выход

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

  • Обработка ввода
  • Бизнес-логика
    • Доступ к данным
  • Производство продукции

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

Да, суперкомпьютер может многое сделать за секунду, но мы все еще говорим о большинстве, общих сценариях. Что общего? CRUD распространен . Вот почему шаблон Ruby on Rails и Active Record имеет такой успех и завоевал такую ​​популярность, потому что он увеличил производительность в одном: CRUD.

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

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

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

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

Этот сон заканчивается в мире сценариев. У вас нет процессора, выполняющего инструкции по умолчанию. У вас есть байт-коды, созданные PHP-компилятором, и это интерпретируется PHP-интерпретатором. В отличие от процессора, интерпретатор PHP имеет дело с понятиями более высокого уровня, такими как абстракции, классы, типы, независимо от того, является ли это байт-кодом. Простое обращение к указателю для CPU - это сложный набор операций для PHP. Разбор операции, понимание операции, возможно, некоторые проверки работоспособности и, наконец, выполнение ее с другим набором байт-кодов.

Следовательно, издержки наследования в мире сценариев на несколько порядков ниже, чем в естественной среде.

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

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

4 голосов
/ 02 февраля 2011

Существует множество причин для использования классов или ООП (объектно-ориентированного программирования).

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

Есть еще много причин, вам нужно просто посмотреть на преимущества / недостатки использования ООП.

2 голосов
/ 02 февраля 2011

Когда мы используем mysql_query(), вы должны предварительно подключиться к БД с помощью mysql_connect() и mysql_select_db().

Каждый раз, когда вы делаете mysql_connect(), это стоит.
Таким образом, вы сделаете один раз mysql_connect() и сохраните $link. И используйте эту ссылку для каждого mysql_query("...", $link)

В объекте это то же самое, но это более элегантно, вы просто создаете экземпляр класса (поэтому он создает соединение с БД) и используете объект, имеющий ссылку.

Если вы измените пароль БД, вы измените его один раз, просто в классе.
Если вы измените MySQL на PostgreSQL, вы перезапишете свой код один раз, просто в классе. Это не повлияет на остальную часть вашего приложения.

2 голосов
/ 02 февраля 2011

Время, затраченное на мое

$db->query()
mysql_query() 

, практически одинаково.

Мы используем не классы для ускорения выполнения кода, а их организацию.

По мере того, как ваш проект становится все больше и больше, вам будет трудно управлять своим кодом.

Если вы возражаете, вы можете создать экземпляр этого объекта и использовать его снова, и к тому же у вашего кода меньшешансы запутаться с другими.

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

0 голосов
/ 02 февраля 2011

Как сказал @frbry, мы используем классы для абстракции. Абстракция необходима для управления и снижения сложности. Когда вы способны «абстрагировать» операции и данные, вы можете сосредоточиться на других вещах и не думать о реализации «изолированных и абстрагированных» вещей при выполнении других вещей.

Это также помогает изменить систему в будущем с меньшим воздействием на другие части кода и снова уменьшить сложность системы.

Существует очень хорошая лекция MIT от 1986 года, которая, как правило, посвящена программированию на LISP, однако она также очень хорошо описывает, почему вам нужно абстрагировать вещи в процедурах (или в чёрных ящиках, которые они называют), - они утверждают, что программное обеспечение разработка заключается в уменьшении сложности.

Вот ссылка: http://www.youtube.com/watch?v=2Op3QLzMgSY

...