Какие парадигмы программирования поддерживает php

Парадигмы программирования — PHP: Функции

В программировании часто используется термин "парадигма".

Паради́гма программи́рования — это совокупность идей и понятий, определяющих стиль написания компьютерных программ (подход к программированию). Это способ концептуализации, определяющий организацию вычислений и структурирование работы, выполняемой компьютером. (Wikipedia)

Парадигма — это больше, чем просто другой алгоритм решения задачи. Как правило, структура кода при использовании разных парадигм отличается очень значительно и требует знаний, выходящих за рамки только синтаксиса языка (например, автоматное программирование требует хотя бы базового понимания теории автоматов). Причём подавляющее большинство современных (и не очень) языков программирования являются мультипарадигменными и позволяют писать код, используя множество стилей. Иногда эти стили взаимоисключающие, иногда они дополняют друг друга. К текущему моменту мы писали код, используя две парадигмы: императивную и декларативную.

Императивная парадигма

Императивная парадигма — стиль написания кода в виде набора последовательных инструкций (команд) с активным использованием переменных. Возможно, данное определение звучит страшно, но на практике императивный стиль является доминирующим. Не считая этого курса, весь остальной код мы писали именно в императивном стиле.

В императивном стиле широко используется присваивание (а, значит, и переменные) и циклы. Эта парадигма популярна потому, что она в точности соответствует тому, как работает компьютер: последовательно выполняет инструкции и использует память для хранения промежуточных результатов. Обычно говорят, что императивная программа отвечает на вопрос КАК («как достичь нужного результата»).

PHP как, впрочем и Java/Ruby/Python/C#/Perl/JavaScript/Go, относится к императивным языкам. То есть языкам, в которых доминирующей является императивная парадигма (язык толкает к её использованию). Что, однако, не мешает использовать и другие парадигмы в рамках этих языков.

Декларативная парадигма

Императивному стилю противопоставляют декларативный, который нередко называют функциональным. Ключевое отличие функционального стиля от императивного в том, что при таком стиле программа выглядит как описание нужного результата, а не как набор инструкций. То есть программа отвечает на вопрос ЧТО («что мы хотим получить»). Эту грань довольно трудно уловить сразу, но, например, вся математика по своей сути декларативна. Например математическое определение факториала фактически является декларативным кодом:

Пример с поиском максимального числа:

Главное отличие декларативной парадигмы от императивной на практике — отсутствие присваивания. Вы можете возразить, что в коде выше переменные есть и чисто технически это правда. Присмотритесь к коду внимательнее, вы заметите что переменная создана ровно один раз и больше не меняется. По сути, она рассматривается как константа или, если копнуть глубже, как логическое высказывание. В математике это звучало бы так: допустим "A — это множество чисел". Что бы мы дальше ни делали, "A" остаётся всегда тем же, чем было во время определения.

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

То же самое касается и $acc с $number . Эти параметры всегда определяются ровно один раз, так как каждый вызов функции при таком определении (без использования ссылок) не зависит от другого вызова (спасибо чистым функциям). В мире функциональных языков такую операцию называют связывание. Визуально оно выглядит как присваивание, но это не оно. Попытка связать уже связанный идентификатор (в функциональных языках нет переменных) завершится ошибкой. Ниже пример на языке Erlang:

Отсутствие присваивания автоматически означает то, что в функциональной парадигме невозможно использование циклов. Вместо них используется рекурсия. Другой важной особенностью функционального стиля считается активное использование функций как объектов первого рода. В основном в функциях высшего порядка. Причём они способны заменить рекурсию в подавляющем большинстве задач, в чем мы уже убедились в предыдущих уроках (убедились так, что даже не рассматривали рекурсию). Любая задача из представленных решалась основной тройкой функций высшего порядка.

Языков, использующих декларативную парадигму, довольно много. Они, в своей массе, менее популярны, чем императивные, но прочно занимают определённые ниши и активно используются в промышленном программировании. К таким языкам относятся: Haskell/Erlang/Elixir/OCaml/F#. В этих языках нет присваивания и циклов. Императивный код на них написать просто невозможно. Немного особняком стоят такие языки, как Scala и Clojure (и другие из семейства LISP). В этих языках основная парадигма — декларативная, и язык толкает к тому, чтобы писать в таком стиле, но при необходимости на них можно написать самый настоящий императивный код с присваиванием и циклами. А вот почти все императивные языки позволяют писать декларативно. Причём, если одни языки имеют довольно слабую поддержку декларативной парадигмы, то другие настолько мощную, что в них можно писать только декларативно (если хочется). К последним относится и современный JavaScript.

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

Другие парадигмы

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

PHP: неправильный путь

В мире PHP-программирования существует набор трендов. Некоторые люди активно продвигают их (в книгах и на сайтах) как «современный PHP», а другие подходы выставляют как устаревшие, глупые или просто неверные.

Похоже, все эти люди без устали стараются заставить каждого программировать так, как они считают нужным. Эта статья написана, чтобы поделиться прагматичным взглядом на PHP-программирование. Взглядом, продиктованным опытом и практическими последствиями, а не популярными тенденциями, теориями или академическими догмами. Материалы, представленные на сайте PHP — The Wrong Way, будут обновляться по мере появления новой информации. Приглашаем всех поучаствовать в этом.

Опасность экстремизма

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

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

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

Принцип KISS, который некоторые расшифровывают как «Keep It Simple, Stupid», — чрезвычайно мудрый и правильный, опытные люди призывают следовать ему. Но даже KISS может стать угрозой для проекта, если довести его до абсурда. Есть такое понятие, как излишняя простота, что в нашем случае приводит к недостатку функциональности.

Неправильный путь: религиозное следование правилам и руководствам.

Постоянное использование фреймворков

В PHP-сообществе по-настоящему плохая тенденция превратилась в де-факто стандарт при разработке веб-приложений. Речь идёт об использовании популярных фреймворков общего назначения.

Это явление широко распространилось. Причина тому — не улучшение результатов разработки и не правильность выполнения каких-то операций с точки зрения технологий и архитектуры. Просто некоторые авторы фреймворков увлекли за собой сообщество разработчиков с помощью полемики, направленной против создания приложений с нуля. Характерными лозунгами стали «Не изобретайте колесо!» и «Не надо всё делать самостоятельно, об этом уже позаботились более опытные».

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

Этим людям настолько нравится увлекать других за собой, становиться своеобразными лидерами мнений в PHP-сообществе, убеждать всех использовать свежие и «модные» open source инструменты, что они забывают удостовериться в осмысленности и толковости своих советов. Фреймворк общего назначения можно сравнить с собранным на фабрике домом. Строительство приложения с помощью такого фреймворка сделает вас кодером или программистом в той же степени, как возведение заранее собранных домов превратит вас в плотника.

В этой статье мы различаем фреймворки и библиотеки по следующим признакам:

Библиотека — это набор многократно используемого кода. Например, стандартные библиотеки С или Go. Код библиотеки можно легко и без ограничений внедрить в проект. Она состоит из маленьких фрагментов, у каждого из них есть конкретная функциональность.
Фреймворк — это не просто набор многократно используемого кода: вы не сможете вырезать кусок из фреймворка и вставить его в проект. Эта система помогает создавать ПО, но в то же время накладывает на вас ограничения, присущие самому фреймворку. Кроме того, во фреймворке немало взаимозависимой функциональности: одна часть не сможет работать без других.

А PHP Расмус Лердорф изначально создавал как набор инструментов, написанных на С, позволяющих легко и быстро разрабатывать динамический HTML. PHP таким задумывался и таким остался, он сам и есть фреймворк.

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

Использовать библиотеки в проектах совершенно естественно. В комплекте поставки PHP идёт набор библиотек, которые могут расширить ваш код. Например, PDO — маленькая библиотека, предоставляющая согласованный интерфейс для обращения к базам данных в PHP.

А вот использование фреймворка поверх PHP — совсем другое дело.

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

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

Чётко уясните: строк кода в любом проекте должно быть как можно меньше, чтобы код стал как можно чище и читабельнее!

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

Всегда используйте прагматичный подход, при котором:

Неправильный путь: всегда использовать фреймворк поверх PHP.

Постоянное использование шаблонов проектирования

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

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

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

Нельзя попадать в ловушку философии или идеи, стоящей за конкретным шаблоном или решением. Наша главная задача — сделать код как можно более лёгким для понимания, а значит, безопасным и простым в сопровождении.

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

Всегда используйте прагматичный подход, при котором:

Неправильный путь: искать шаблон для решения проблемы.

Постоянное использование объектно ориентированного программирования

Многие разработчики и компании сегодня считают, что ООП — единственный оправданный способ разработки. А те, кто с этим спорят, немедленно осознают, что идут против «общепринятого мнения» индустрии.

Блоги и форумы, посвящённые программированию, полны защитников ООП, уверенных в том, что они понимают, о чём говорят, хотя какого-либо стандартного определения не существует.

Но дело в том, что так называемое объектно ориентированное программирование очень часто бывает излишне сложным!

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

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

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

Маленький исторический урок

Один из лучших способов понять парадигму программирования — посмотреть, как она возникла. В чём причина? Из-за каких проблем в других парадигмах понадобился новый подход? Была ли проблема практическая или академическая? И сколько времени прошло с момента создания парадигмы?

Неважно, что говорит человек Х или какое определение даёт человек Y. Важны исторические предпосылки возникновения парадигм.

Раньше, ещё до пришествия ООП, примерно в конце 1950-х, для создания многих программ использовали языки с упором на неструктурированное программирование. Их иногда называют языками первого и второго поколений. Неструктурированное программирование исторически стало первой парадигмой. Её активно критиковали за спагетти-код.

Есть и высоко-, и низкоуровневые языки, использующие неструктурированное программирование. Например, BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, машинный код, ранние системы ассемблера (без процедурных метаоператоров), ряд скриптовых языков. Программа на неструктурированном языке обычно состоит из последовательно расположенных команд или выражений, обычно по одной на строку. Строки либо нумеруются, либо могут содержать метки, позволяющие потоку выполнения переходить к любой из строк (вроде непопулярного выражения GOTO). В 1960-х появилось структурное программирование, во многом благодаря известному письму Эдсгера Дейкстра Go To statements considered harmful.

Структурное программирование — это парадигма, улучшающая чистоту, качество и процесс разработки с помощью подпрограмм, блочных структур и циклов. Это в противовес простому перепрыгиванию выражения GOTO.

Затем из структурированного программирования возникло процедурное. В его основе лежит концепция «вызова процедуры». Это ещё одно название для «вызова функции». Процедуры также известны вам как подпрограммы или методы. По сути, это серия вычислений, которые необходимо выполнить. Любая процедура может быть вызвана другими процедурами или самостоятельно в любое время в ходе исполнения программы.

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

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

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

Затем, в основном из-за появления Java, появились новые модные термины, а «процедуру», или «функцию», переименовали в «метод», когда он принадлежит отдельной области видимости. Переменные переименовали в «атрибуты», когда они принадлежат отдельной области видимости.

Так что объект, по сути, — это просто набор функций и переменных, которые теперь называют методами и атрибутами.

Методы и атрибуты изолируются внутри отдельной области видимости с помощью «класса». А когда создаётся экземпляр класса, он называется объектом.

Объекты могут ссылаться друг на друга, и благодаря этому методы (функции) внутри них тоже «взаимодействуют» друг с другом. Также объекты могут «наследовать» методы от других объектов, тем самым расширяя их, это называется «наследование». Это способ многократного использования кода, позволяющий создавать независимые расширения приложений через публичные классы и интерфейсы. Взаимосвязи между объектами породили иерархию. Наследование было создано в 1967 году для языка Simula 67.

Объекты также могут наследовать методы от других объектов и «переопределять» их с помощью дополнительной или изменённой функциональности, это называется «полиморфизм».

В разных языках эти идеи реализованы очень по-разному.

Объектно ориентированное программирование — это иной способ организации кода. Это расширение процедурного программирования, связанное с сокрытием данных (инкапсуляцией) и избеганием глобальных областей видимости. Это расширение функций посредством «заимствования» их чертежей без влияния на оригинальный код (наследование). И это переопределение функций без влияния на оригинальный код (полиморфизм).

Неправильный путь: всегда использовать объектно ориентированное программирование.

Бояться чужого кода

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

Это довольно странное мышление, в основном характерное для веб-разработчиков, говорит о недостатке профессионализма и опыта.

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

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

Профессионалы так не думают. Ни один.

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

Программирование во многом подразумевает взаимодействие с людьми, использующими чужой код. Это часть работы: пытаться улучшить существующую кодовую базу, и иногда приходится её полностью переписывать. Почитайте, что говорят мастера программирования в книге Coders at work. Reflections on the Craft of Programming.

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

Ядро Linux содержит более 20 миллионов строк кода, написанных исключительно с помощью процедурного программирования. В его создании участвовали 14 тысяч человек — и никаких фреймворков. Разные возможности BSD и большая часть Linux GNU userland также написаны только с помощью процедурного программирования без применения фреймворков.

То же самое можно сказать о сотнях open source проектов по всему миру, заброшенных авторами только для того, чтобы их подхватили другие опытные программисты. По многим из этих проектов очень мало документации (или её вообще нет), нет комментариев в коде, нет руководств или иных видов помощи.

Да чего уж там — вся кодовая база PHP написана на С, процедурном языке, без фреймворков.

Когда вы определяете класс в PHP или когда вы запускаете свой любимый PHP-фреймворк, вы выполняете чью-то процедурную работу!

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

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

Как программисты, мы должны предотвращать такие ситуации, но это нормально, в этом заключается искусство программирования, это часть того, что называется быть программистом!

Неправильный путь: бояться кода, написанного другими.

Следование стандартам PHP-FIG

FIG расшифровывается как Framework Interoperability Group (Группа по совместимости фреймворков).

PHP-FIG была создана разработчиками фреймворков на конференции php|tek в 2009 году. С тех пор её состав увеличился с 5 до 20 участников.

С PHP-FIG связано много споров. Одни считают это лучшим начинанием PHP-сообщества со времён возникновения самого PHP. Другие уверены, что стоит вообще поскорее забыть о существовании этой группы.

Одна из проблем заключается в том, как PHP-FIG позиционирует себя в своём FAQ:

Однако если мы посмотрим на работу нескольких участников группы, становится очевидно, что реальная цель полностью противоречит заявленному. Группа всячески старается превратить PHP-FIG в «группу PHP-стандартов», что было их первоначальным названием. В книгах участников группы, на их сайтах, в блогах, на форумах и т. д. работу PHP-FIG именуют современным PHP, а все остальные подходы объявляют устаревшими.

Проблема PHP-FIG в том, что, хотя многие фреймворки и open source-проекты внедрили у себя ряд стандартов группы, сами эти стандарты в основном призваны решать проблемы «с точки зрения фреймворка», что делает их бесполезными во многих практических ситуациях.

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

Если и нужна какая-то группа, то её стандарты должны отражать интересы всего PHP-сообщества, а не одних лишь разработчиков фреймворков и open source CMS проектов. Такая группа должна представлять разработчиков самого языка PHP, с гораздо большим количеством участников, причём с правом голоса.

Если вы решили следовать стандартам PHP-FIG, то вы должны понимать, что некоторые из них — например, стандарты автозагрузчика PSR-0 и PSR-4 и ряд других — напрямую влияют на то, как вы пишете код ПО.

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

Неправильный путь: следовать стандартам PHP-FIG, за исключением PSR-1 и PSR-2.

Пренебрежение безопасностью

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

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

Нельзя просто добавить безопасность в приложение!

Чтобы сделать небезопасное приложение безопасным, возможно, придётся существенно перепроектировать его. Вы должны определять происхождение угроз для вашего ПО и внедрять методики безопасного кода с самого начала, придерживаясь их в течение всего планирования и разработки приложения.

Безопасность критических программных ресурсов сегодня важна как никогда, поскольку основной вектор атак неуклонно перемещается на уровень приложения. По итогам исследования SANS 2009 года, атаки против веб-приложений составили более 60 % всех атак, зарегистрированных в интернете.

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

Безопасность по умолчанию

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

Неправильный путь: не разрабатывать приложение безопасным по умолчанию.

Всё вышеописанное легко понять неправильно — давайте кое-что проясним.

В чём цель вашего сайта и почему вы плывёте против течения?
Цель — начать дискуссию о современных методиках и крайних точках зрения.

Так вы говорите, что объектно ориентированное программирование это плохо или хорошо?
Нет, конечно, нет! Речь о том, чтобы вы понимали: не стоит решать все проблемы исключительно посредством ОО-парадигмы. Нельзя делить всё на чёрное и белое, это ошибка. В рамках одного приложения могут существовать самые разные проблемы, и иногда лучший выход — использовать разные парадигмы в зависимости от конкретной ситуации. А если вы решаете проблему с помощью неподходящего способа, то ни к чему хорошему это не приведёт.

Вы говорите, что фреймворки — зло?
Мы не осуждаем конкретно фреймворки. Мы осуждаем лишь их постоянное использование поверх PHP.

Если фреймворк помогает мне быстро начать и продолжить работать, что в этом плохого?
Если вы проанализируете ситуацию и долгосрочные последствия и поймёте, что «быстро начать и продолжить работать» — единственная проблема, которую вы когда-либо решали, то в этом нет ничего плохого. Но тогда мы говорим не о программировании или разработке ПО, а об использовании point-and-click решений.

Быстро начать и продолжить работать — это не создание приложения; это означает, что вы не анализировали проблему и не осознали долгосрочных последствий своего выбора.

Вы хотите сказать, что сторонние пакеты — это плохо?
Нет. Мы рекомендуем использовать сторонние библиотеки. Код, который вы можете легко и без ограничений внедрять в свои проекты. Это отличная возможность!

Кто вы?
Наш сайт посвящён идее борьбы с экстремизмом в PHP-сообществе, а не личному продвижению или обретению известности. Если мы раскроем имена — это лишь отвлечёт внимание от поднятых на сайте проблем. Давайте не будем отвлекаться.

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

Тест с ответами: «PHP»

1. Вы передаете ассоциативный массив в функцию sort(). Каким будет результат выполнения функции:
а) массив будут отсортирован по значениям. Ключи элементов отсортированы не будут и не будут сохранены +
б) массив будут отсортирован по значениям. Ключи элементов отсортированы не будут, но будут сохранены
в) массив будут отсортирован по ключам. Значения элементов отсортированы не будут

2. Какую парадигму программирования поддерживает PHP:
а) логическую
б) процедурную +
в) логистическую

3. Какую парадигму программирования поддерживает PHP:
а) логистическую
б) логическую
в) объектно-ориентированную +

4. Какой оператор обозначает равенство значений в языке PHP:
а) == +
б) =
в) :=

5. Как можно задать массив в языке PHP:
а) $arr[«a»,»b»,»c»] = «q»;
б) $arr («0″=> «a»);
в) $arr = array(«a»,»b»,»c»); +

6. Как можно задать массив в языке PHP:
а) $arr («0″=> «a»);
б) $arr[0] = «a»; +
в) $arr[«a»,»b»,»c»] = «q»;

7. Какое из утверждений относительно оператора require верно:
а) при использовании внутри условных блоков require не нужно заключать в фигурные скобки
б) require выполняет код указанного в нем файла только один раз
в) require используется для включения в программу содержимого другого файла +

8. Какое из утверждений относительно оператора include верно:
а) include используется для включения в программу содержимого другого файла +
б) файл, включаемый с помощью include, должен быть правильным HTML-файлом
в) файл, включаемый с помощью include, может быть любым файлом

9. Чем отличается клиент от сервера:
а) сервер создает соединение, а клиент, пользуясь им, передает свой запрос
б) сервер есть часть компьютерной архитектуры сервер-сервер, а клиент – архитектуры клиент-клиент
в) клиент посылает запросы, а сервер обрабатывает их +

10. Чем отличается клиент от сервера:
а) сервер создает соединение, а клиент, пользуясь им, передает свой запрос
б) клиент отображает данные на экране компьютера пользователя, а сервер предоставляет данные +
в) сервер есть часть компьютерной архитектуры сервер-сервер, а клиент – архитектуры клиент-клиент

11. В чем состоит одна из функций сервера:
а) обрабатывать запросы клиента +
б) отображать данные на экране компьютера пользователя
в) инициировать соединение с клиентом

12. В чем состоит одна из функций сервера:
а) отображать данные на экране компьютера пользователя
б) запускать процессы, запрошенные клиентом, и возвращать клиенту результаты +
в) инициировать соединение с клиентом

13. Как можно получить и вывести на экран список всех методов класса, представителем которого является объект:
а) get_class_methods(get_class(объект)); +
б) get_methods(get_class(объект));
в) get_class_methods(get_class -> объект);

14. Имеется объект ($obj) какого-то класса. Требуется получить список всех свойств класса, которому принадлежит объект:
а) get_class_var(get_class($obj));
б) $get_class_vars(get_class->$obj);
в) $vars = get_class_vars(get_class($obj)); +

15. Как можно программно узнать имя класса, представителем которого является объект:
а) get_class(объект); +
б) $(get_class->объект);
в) class(объект);

16. С помощью какой функции можно получить текущее смещение чтения/записи файла:
а) fread
б) ftell() +
в) fseek()

17. Какая функция добавляет новый элемент в начало массива:
а) array_shift()
б) array_pop()
в) array_unshift() +

18. Какую функция возвращает метку времени (timestamp):
а) date()
б) strtotime() +
в) localtime()

19. Какую функция возвращает метку времени (timestamp):
а) localtime()
б) date()
в) time() +

20. Каким HTTP методом по умолчанию отправляются данные из веб-формы:
а) OPTIONS
б) GET +
в) PUT

21. Что делает функция move_uploaded_file (временное имя файла, место назначения):
а) проверяет, загружен ли файл, и если да, то перемещает его из временной директории в указанную директорию для хранения +
б) удаляет загруженный файл
в) перемещает файл из временной директории в указанную директорию для хранения

22. С помощью какой функции можно проверить, существует ли файл:
а) is_readable()
б) file_exists() +
в) is_writable()

23. Каков синтаксис оператора удаления таблицы:
а) REMOVE TABLE [IF EXISTS] имя_таблицы [, имя_таблицы,…] [RESTRICT | CASCADE]
б) DELETE TABLE [IF EXISTS] имя_таблицы [, имя_таблицы,…] [RESTRICT | CASCADE]
в) DROP TABLE [IF EXISTS] имя_таблицы [, имя_таблицы,…] [RESTRICT | CASCADE] +

24. Составить запрос к таблице описаний статей (Articles): изменить название статьи (title), автор (author) которой «Петров» на название «Второе название»:
а) UPDATE Articles SET title=»Второе название»;
б) UPDATE Articles SET title=»Второе название» WHERE author=»Петров»; +
в) UPDATE Articles SET title=»Второе название» WHERE title=» Первое название»;

25. Каковы синтаксис и семантика функции explode:
а) эта функция без параметров. Ее семантика неизвестна
б) массив explode (строка string). Эта функция разбивает строку string на части с помощью разделителя » » и возвращает массив полученных строк
в) массив explode(строка separator, строка string [, int limit]). Эта функция разбивает строку string на части с помощью разделителя separator и возвращает массив полученных строк +

26. Параметр session.cookie_lifetime задает длительность жизни cookies в секундах. Какое значение имеет этот параметр по умолчанию:
а) по умолчанию это «10», т.е. данные в cookies считаются правильными ровно 10 секунд
б) по умолчанию это «0», т.е. данные в cookies считаются правильными до закрытия окна браузера +
в) по умолчанию это «60»

27. Уничтожить текущую сессию целиком можно командой session_destroy(); К чему приведет уничтожение сессии:
а) после уничтожения сессии уничтожается ее идентификатор, мы больше не можем ни регистрировать переменные, ни вообще производить какие-либо действия с сессией +
б) после уничтожения сессии очищается массив $_SESSION и больше ничего не происходит
в) после уничтожения сессии массив $_SESSION заполняется нулями

28. С помощью какой функции можно получить идентификатор сессии:
а) id_session
б) session_id +
в) session_identificator

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

30. Назначение метасимвола «-«:
а) вычисляет символьный класс
б) задает диапазон символов +
в) отрицание класса, но только если это первый символ

Язык программирования PHP — ответы на тесты Интуит

использование func_num_args , приведенное ниже, верно, и результатом работы скрипта будет число 2.

cначала нужно создать форму (файл form.html ) вида:

<h2>Внесение статьи в каталог</h2> <form action=»2.php» method=GET> Название статьи:<br> <input type=text name=title> <br>Автор статьи:<br><input type=text name=author> <p> <input type=submit value=send> </form>

Затем нужно создать скрипт 2.php для обработки этой формы:

<?php $str = » Статья под названием «; $str .= «<font color=red>» . $_GET[«title»]. «</font> «; $str .= » автора <font color=red>» . $_GET[«author»] .»</font> внесена в каталог.»; echo $str; ?>

сначала нужно создать форму (файл form.html ) вида:

<h2>Внесение статьи в каталог</h2> <form action=»2.php» method=POST> Название статьи:<br> <input type=text name=title> <br>Автор статьи:<br> <input type=text name=author> <p><input type=submit value=send></form>

Затем нужно создать скрипт 2.php для обработки этой формы:

сначала нужно создать форму (файл form.html ) вида:

<h2>Внесение статьи в каталог</h2> <form action=»2.php» method=GET> Название статьи:<br> <input type=text name=title> <br>Автор статьи:<br> <input type=text name=author> <p><input type=submit value=send></form>

Затем нужно создать скрипт 2.php для обработки этой формы:

<?php $str = » Статья под названием «; $str .= «<font color=red>» .GET[«title»]. «</font> «; $str .= » автора <font color=red>» .GET[«author»] .»</font> внесена в каталог.»; echo $str; ?>

Создать функцию для отображения данных из следующей формы:

<form action=»test.php»> Название <input type=text name=title><br> Автор <input type=text name=creator><br> Краткое содержание <textarea name=descr> </textarea> <input type=submit> </form>

Имеется форма для выбора записи, предназначенной для удаления:

<form action=task3.php> Запись номер 1 <input type=checkbox name=id[] value=first> <br> Запись номер 2 <input type=checkbox name=id[] value=second> <br> Запись номер 3 <input type=checkbox name=id[] value=third> <br> <input type=submit value=»Удалить»> </form>

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

Дано предложение: «Пролетарии всех стран, объединяйтесь!»

Как можно заменить в предложении слово «Пролетарии» на слово «Женщины»?

Дана следующая html форма:

<form method=»post» name=»my_form»> Field 1 <input type=text name=»f1″><br> Text <textarea name=»f2″> </textarea> <input type=submit> </form>

Как можно получить переданные клиентом значения из этой формы?

Каким будет результат работы программы?

Класс MyClass задан следующим образом:

Создать представителя класса MyClass . Получить и вывести значения всех свойств этого класса. Вызвать методы данного класса.

Конструктор MyClass() вызывается автоматически при создании представителя класса.

нужно зарегистрировать переменную в качестве переменной сессии:

$_SESSION[«user_name»] = «Иван Петров»;

в этом скрипте нужно создать сессию (или восстановить текущую) с помощью команды session_start() . Потом нужно зарегистрировать переменную в качестве переменной сессии таким образом:

$_SESSION[«user_name»] = «Иван Петров»;

Все остальные скрипты программы начинать с команды session_start();

$_SESSION[«user_name»] = «Иван Петров»;

Что делает следующая функция?

function Test($str)< $pattern = "/\d<3>-\d<2>-\d<2>/m»; $num_match = preg_match_all ($pattern, $str, $result); return $num_match; >

Имеется два шаблона

Используя класс для работы с FastTemplate , написать программу, которая по данным шаблонам генерирует html-страницу с заголовком «Test page» и содержанием вида:

Name: Иван Last Name: Петров

Что делает приведенная ниже программа?

<?php $f = fopen(«file.html», «w+»); fwrite($f, «Hello»); fclose($f); ?>

Имеется следующий xml-документ ( data.xml ):

<?xml version=»1.0″?> <root> <person num=»10″> <name>Nick Petrov</name> </person> <person num=»20″> <name>Pit Ivanov</name> </person> </root>

Преобразовать данные этого файла в массивы, содержащие информацию о каждой персоне (Например, Array(«num»=>»10», «name»=>»Nick Petrov») )

Чему будет равна переменная $result в результате выполнения следующей программы

Имеется следующая html-форма

<form enctype=»multipart/form-data» action=»parse.php» method=»post»> <input type=»hidden» name=»MAX_FILE_SIZE» value=»30000″ /> Загрузить файл: <input type=»file» name=»my» /><br> <input type=»submit» value=»Отправить файл» /> </form>

Как узнать имя файла, который клиент хочет загрузить на сервер с помощью этой формы.

Что мы получим в результате обработки интерпретатором файла index.php ?

сначала нужно создать форму (файл form.html ) такого вида:

<h2>Внесение статьи в каталог</h2> <form action=»parser.php» method=POST> Название статьи:<br> <input type=text name=title> <br>Краткое содержание статьи:<br> <textarea name=description> </textarea> <p><input type=submit value=send> </form>

Затем нужно создать скрипт parser.php для обработки этой формы:

<?php echo » Статья под названием » . «<font color=red>». $_POST[«title»]. «</font> внесена в каталог.<br>»; echo «Краткое содержание статьи состоит в следующем: <br>». $_POST[«description»]; ?>

в строке запроса в браузере нужно написать следующее:

nina/test/parser.php?title=Первый компьютер&description=Это статья про первый советский компьютер

Затем создать скрипт 2.php для обработки этой формы:

сначала нужно создать форму (файл form.html ) вида:

Затем нужно создать скрипт parser.php для обработки этой формы:

<?php echo » Статья под названием » . «<font color=red>». $HTTP_POST_VARS[«title»]. «</font> внесена в каталог.<br>»; echo «Краткое содержание статьи состоит в следующем: <br>». $HTTP_POST_VARS [«description»]; ?>

cначала нужно создать форму (файл form.html ) вида:

Затем нужно создать скрипт parser.php для обработки этой формы:

<?php echo » Статья под названием » . «<font color=red>». $_REQUEST[«title»]. «</font> внесена в каталог.<br>»; echo «Краткое содержание статьи состоит в следующем: <br>». $_REQUEST[«description»]; ?>

Какие парадигмы программирования поддерживает php

Парадигмы программирования — PHP: Функции

Императивная парадигма

Декларативная парадигма

Другие парадигмы

PHP: неправильный путь

Опасность экстремизма

Постоянное использование фреймворков

Постоянное использование шаблонов проектирования

Постоянное использование объектно ориентированного программирования

Маленький исторический урок

Бояться чужого кода

Следование стандартам PHP-FIG

Пренебрежение безопасностью

Безопасность по умолчанию

Рекомендуемая литература

Тест с ответами: «PHP»

Язык программирования PHP — ответы на тесты Интуит

Добавить комментарий Отменить ответ