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