Глубокая подготовка по программированию на PHP 8.0

Основы PHP 8.0 и современные возможности языка

Роль PHP 8.0 в современной веб-разработке

PHP — серверный язык программирования, который чаще всего используют для создания веб-приложений и API. Код PHP исполняется на сервере, а клиент (браузер или мобильное приложение) получает уже готовый результат: HTML, JSON и т.д.

PHP 8.0 — крупный релиз, который усилил типизацию, добавил новые конструкции языка и улучшил производительность (в том числе за счёт JIT). В этом курсе мы будем писать код так, как принято в современной PHP-разработке: с понятной структурой, типами, предсказуемым поведением и ясной обработкой ошибок.

!Схема показывает, где именно исполняется PHP-код и как запрос проходит через инфраструктуру

Запуск PHP и базовая структура программы

Способы запуска

* Через веб-сервер (типичный продакшен): Nginx/Apache + PHP-FPM. * Через встроенный сервер для разработки: php -S localhost:8000 -t public. * Через CLI (консольные скрипты): php script.php.

Официальная документация по CLI:

* PHP Command line usage

Минимальный пример

Ключевые элементы:

* <?php — начало PHP-кода. * declare(strict_types=1); — включает строгую проверку типов для аргументов и возвращаемых значений в текущем файле. * echo — вывод строки.

Документация:

* declare

Переменные, типы и строгая типизация

Переменные и базовые типы

Переменные в PHP начинаются с a, int a + userId): ?string { // Если не найдено — возвращаем null return null; } php config['limit'] ?? 100; php user?->getProfile()?->getEmail();

Документация:

* Named arguments

Стрелочные функции

Стрелочные функции (fn) удобны для коротких колбэков и автоматически захватывают переменные из внешней области видимости по значению.

Документация:

* match

Ошибки и исключения

Ошибки vs исключения

В современном PHP-коде предпочтительно обрабатывать проблемные ситуации через исключения.

Promotion свойств конструктора (PHP 8.0)

PHP 8.0 позволяет объявлять и инициализировать свойства прямо в параметрах конструктора.

Документация:

* Namespaces

Composer и PSR-4 (почему это важно)

В реальных проектах автозагрузка классов обычно настраивается через Composer и стандарт PSR-4. Это позволяет не писать вручную require/include для каждого файла.

Документация:

* Composer

Система типов PHP 8.0: union types и mixed

Union types (PHP 8.0)

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

Это лучше, чем оставлять тип неуказанным, потому что контракт становится явным.

Документация:

* Union Types

mixed

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

Документация:

* mixed

Атрибуты (PHP 8.0)

Атрибуты — встроенный способ добавлять метаданные к классам, методам, свойствам, параметрам. Это замена части сценариев, где раньше использовали docblock-аннотации.

Пример: пометим метод как устаревший (демонстрация идеи).

Атрибуты читаются через Reflection (к этому мы подойдём позже в курсе, когда будем разбирать метапрограммирование и инструменты фреймворков).

Документация:

* Attributes

Производительность и JIT

PHP 8.0 включает JIT (Just-In-Time compiler) как часть движка OPcache. Важно понимать практический вывод:

* JIT не всегда ускоряет типичные веб-запросы так сильно, как вычислительные задачи. * Главные выигрыши в вебе часто дают архитектура, кэширование, оптимизация запросов в БД и снижение I/O.

Тем не менее, сам факт появления JIT — показатель движения PHP в сторону более высокой производительности.

Документация:

* OPcache

Рекомендуемый стиль кода и минимальные правила качества

Чтобы код был поддерживаемым, с первого занятия закрепим базовые правила:

* Включайте declare(strict_types=1); в файлах с бизнес-логикой. * Всегда указывайте типы аргументов и возвращаемых значений, где это разумно. * Избегайте «магических» значений: используйте константы, enum (появится в PHP 8.1) или отдельные типы. * Предпочитайте исключения молчаливым ошибкам. * Разделяйте ответственность: функции и классы должны делать одну понятную вещь.

Итоги

В этой статье вы:

* разобрали, как запускается PHP и зачем нужен strict_types * закрепили базовые типы и работу с null * познакомились с ключевыми возможностями PHP 8.0: match, именованные аргументы, union types, nullsafe operator, promotion свойств конструктора, атрибуты, throw` как выражение * увидели основу ООП, namespaces и роль Composer

В следующих материалах курса мы будем углублять эти основы: детально разберём массивы и строки, работу с датой/временем, I/O, затем перейдём к архитектуре приложений, тестированию и практикам промышленной разработки на PHP 8.

Типизация, исключения и работа с ошибками

Как эта тема связана с предыдущим материалом

В предыдущей статье мы включили declare(strict_types=1);, познакомились с базовыми типами, match, throw как выражением и общими принципами современного PHP 8.0. Теперь углубимся в две ключевые практики промышленной разработки:

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

Типизация в PHP 8.0 как контракт

Тип в современном PHP стоит воспринимать как контракт между тем, кто вызывает функцию или метод, и тем, кто её реализует.

Если контракт нарушен, PHP 8.0 чаще всего прерывает выполнение и выбрасывает TypeError. Это хорошо: проблема обнаруживается сразу, а не превращается в неявный баг.

Документация:

strict_types и границы строгой типизации

declare(strict_types=1); влияет на то, как PHP проверяет типы аргументов и возвращаемых значений в текущем файле.

Пример с аргументами:

Важно понимать границу:

Документация:

Скаляры и типовые ловушки

PHP имеет скалярные типы int, float, string, bool. Важно отличать:

Пример: пользовательский ввод почти всегда строка.

Практическое правило:

Возвращаемые типы void и типизация результата

Если метод ничего не возвращает, используйте : void. Это делает API класса яснее.

Тип возвращаемого значения особенно важен, потому что:

Документация:

Nullable-типы и null как часть контракта

Если null допустим, это должно быть отражено в типе.

Документация:

Ошибки типизации на практике

При нарушении контракта вы чаще всего увидите:

Документация:

Исключения как инструмент управления ошибками

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

Документация:

Throwable: общее для Exception и Error

В PHP 8.0 и Exception, и Error реализуют интерфейс Throwable. Это означает, что в catch можно перехватывать как прикладные исключения, так и многие ошибки движка.

В PHP 8.0 throw стал выражением, что удобно для компактной валидации:

Важно:

try/catch/finally и управление ресурсами

Базовый шаблон:

finally полезен для освобождения ресурсов, даже если что-то пошло не так:

Документация:

Создание своих исключений

Собственные исключения помогают:

Важно:

Документация:

Практическая стратегия: где проверять типы, а где ловить исключения

Удобная модель для приложения:

!Диаграмма показывает, где выполнять приведение типов и как исключения проходят через слои приложения

Ключевые правила:

Итоги

В этой статье вы:

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

ООП в PHP: классы, интерфейсы, трейты и SOLID

Зачем ООП в курсе про PHP 8.0

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

ООП особенно полезно, когда проект растёт:

Документация:

Базовые понятия ООП без «магии»

В контексте PHP 8.0 нам нужны четыре идеи.

Почти всегда в прикладном коде выигрывает связка: композиция + интерфейсы + явные исключения.

Классы в PHP 8.0 как носители инвариантов

Класс — это не просто набор методов. В хорошей модели класс отвечает за инварианты — правила корректности состояния.

Пример: объект Email гарантирует, что внутри него всегда валидный email. Тогда остальной код может доверять типу Email и не повторять проверки.

Ключевая выгода интерфейсов:

Документация:

Композиция и внедрение зависимостей через интерфейсы

Рассмотрим класс, которому нужно отправлять письма. Если он напрямую создаёт конкретный транспорт, он становится жёстко связанным с реализацией.

Лучше: зависеть от интерфейса.

Если два трейта добавляют одинаковый метод, конфликт решается явно.

Документация:

Когда выбирать класс, интерфейс или трейт

В прикладном коде помогает простая «шпаргалка».

Если сомневаетесь, начните с интерфейса + композиции. Трейты подключайте только при явной повторяемости кода.

SOLID в контексте PHP 8.0

SOLID — это набор принципов проектирования, которые помогают снижать связанность и делать код расширяемым. Здесь важно не «заучить аббревиатуру», а понимать практический смысл.

Источник:

Single Responsibility Principle

Один модуль — одна причина для изменения.

Плохой признак: класс одновременно валидирует входные данные, пишет в БД, отправляет письма и логирует.

Хорошая практика:

Open-Closed Principle

Сущности должны быть открыты для расширения, но закрыты для модификации.

Типичный путь в PHP: добавлять новые реализации интерфейса, не трогая код, который от интерфейса зависит.

Документация:

Практические рекомендации по дизайну в стиле PHP 8.0

Итоги

В этой статье вы:

Работа с данными: PDO, MySQL, транзакции и миграции

Как эта тема связана с предыдущими статьями

Ранее в курсе мы закрепили три фундаментальные опоры современного PHP 8.0:

Работа с базой данных объединяет все эти практики: мы будем получать данные на границе системы, валидировать и типизировать их, выполнять запросы безопасно (без SQL-инъекций), а ошибки инфраструктуры превращать в понятные исключения домена.

!Схема показывает, где именно находится PDO-слой и как через него проходят данные и ошибки

MySQL и подключение через PDO

Почему PDO

PDO (PHP Data Objects) — стандартный слой доступа к данным в PHP, который:

Документация:

DSN и создание подключения

Для MySQL чаще всего используется драйвер pdo_mysql и DSN вида mysql:host=...;dbname=...;charset=....

Критически важные настройки PDO для промышленного кода:

Документация:

Пример подключения:

Практическое правило: храните DSN и пароль вне кода (переменные окружения, секреты CI/CD), а в репозиторий не коммитьте реальные доступы.

Безопасные запросы: подготовленные выражения

Почему нельзя собирать SQL строкой

SQL-инъекция появляется, когда вы вставляете пользовательский ввод прямо в SQL:

public function findIdByEmail(string stmt = stmt->execute(['email' => row = row === false) { return null; }

return (int)row['id'] делается на границе между БД (строки) и доменной логикой (строгие типы)

INSERT и получение lastInsertId

Польза: вы снижаете риск неочевидных преобразований и делаете намерение кода явным.

Чтение данных: fetch modes и форма результата

По умолчанию мы выставили PDO::FETCH_ASSOC, поэтому fetch() и fetchAll() возвращают массивы, где ключи — имена колонок.

Документация:

Практические рекомендации:

Ошибки БД и стратегия исключений

Что именно бросает PDO

Если включён PDO::ERRMODE_EXCEPTION, ошибки запросов и соединения обычно превращаются в PDOException.

Документация:

Оборачивание инфраструктурных ошибок в прикладные

Свяжем это с SOLID и принципом инверсии зависимостей: бизнес-слой не должен зависеть от деталей PDO. Часто удобнее поймать PDOException и выбросить исключение своего слоя.

php <?php

declare(strict_types=1);

final class RegistrationService { public function __construct( private PDO email): int { stmt = stmt->execute(['email' => userId = (int)stmt = stmt->execute(['uid' => this->pdo->commit();

return e) { if (this->pdo->rollBack(); }

throw value) { value); if (value, FILTER_VALIDATE_EMAIL) === false) { throw new InvalidArgumentException('Invalid email'); } value; }

public function asString(): string { return id, private Email this->id; } public function email(): Email { return id): User; }

final class UserNotFoundException extends RuntimeException {} final class UserStorageException extends RuntimeException {}

final class PdoUserRepository implements UserRepository { public function __construct(private PDO id): User { try { this->pdo->prepare('SELECT id, email FROM users WHERE id = :id'); id]); stmt->fetch();

if (id not found"); }

return new User( (int)row['email']) ); } catch (UserNotFoundException e; } catch (PDOException e); } } } ``

Здесь видно ключевое:

Итоги

В этой статье вы:

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

Веб‑разработка: HTTP, маршрутизация, формы и сессии

Связь с предыдущими темами курса

Ранее мы уже построили фундамент «промышленного» PHP 8.0:

Веб‑разработка соединяет эти темы. HTTP‑запрос приносит сырой ввод (строки, заголовки, тело), который нужно:

!Общая картина: как запрос проходит через фронт‑контроллер, роутер и обработчики до ответа

HTTP как основа веб‑приложений

HTTP — протокол, через который клиент (браузер, мобильное приложение) общается с сервером.

> “HTTP is a stateless request/response protocol.” — RFC 9110 > > Источник: RFC 9110: HTTP Semantics

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

Из чего состоит HTTP‑запрос

Обычно полезно мыслить так:

В PHP многие части запроса доступны через суперглобальные массивы:

Документация:

Из чего состоит HTTP‑ответ

Ответ, который сервер возвращает клиенту, включает:

В PHP заголовки и статус обычно задают функцией header().

Документация:

Методы, «безопасность» и идемпотентность

На практике важно понимать смысл методов:

В типичном PHP‑приложении без сложного API чаще всего используются GET и POST, но роутер почти всегда стоит проектировать так, чтобы он учитывал метод.

Справка:

Статус‑коды, которые вы будете видеть постоянно

| Код | Смысл | Когда применять | | --- | --- | --- | | 200 | OK | успешный ответ с телом | | 201 | Created | создан ресурс (часто в API) | | 302 | Found | редирект после POST (часто) | | 303 | See Other | редирект после POST на GET (явный PRG) | | 400 | Bad Request | неверный формат/параметры запроса | | 401 | Unauthorized | не аутентифицирован | | 403 | Forbidden | нет прав | | 404 | Not Found | маршрут/ресурс не найден | | 422 | Unprocessable Content | валидация не прошла | | 500 | Internal Server Error | непредвиденная ошибка |

Справка:

Front Controller и маршрутизация

Почему почти все PHP‑приложения используют front controller

Front controller — это один входной файл, который принимает все запросы и решает, что делать дальше. Обычно это public/index.php.

Плюсы подхода:

Минимальная структура проекта

Типичная раскладка:

Объекты Request и Response как типизированная граница

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

Ниже — упрощённые классы Request и Response.

Мы используем match из PHP 8.0 и исключения, чтобы:

Front controller с централизованной обработкой ошибок

Теперь соберём public/index.php.

php <?php

declare(strict_types=1);

function csrfToken(): string { if (session_status() !== PHP_SESSION_ACTIVE) { session_start(); }

_SESSION['csrf'] ?? null; if (!is_string(token === '') { _SESSION['csrf'] = token; }

function assertCsrfToken(mixed expected = expected) || !is_string(expected, _SESSION — массив, который PHP загружает и сохраняет автоматически при session_start()

Документация:

Базовое использование сессии

Документация:

Flash‑сообщения через сессию

Flash — сообщение «показать один раз после редиректа». Это идеально сочетается с PRG.

`php <?php

declare(strict_types=1);

function flashSet(string value): void { if (session_status() !== PHP_SESSION_ACTIVE) { session_start(); } key] = key): ?string { if (session_status() !== PHP_SESSION_ACTIVE) { session_start(); }

_SESSION['flash'][_SESSION['flash'][value) ? router->get('/login', function (Request token = csrfToken(); html = ''; if (html .= '<p>' . e(html .= '<form method="POST" action="/login">' . '<input type="hidden" name="csrf" value="' . e(html); });

r): Response { try { assertCsrfToken(email = requireNonEmptyString(email = requireEmail(_SESSION['user_email'] = e) { flashSet('error', router->get('/profile', function (Request email = email)) { return Response::redirect('/login'); }

return Response::html('<h1>Profile</h1><p>' . e(_GET/_SERVER на границе (Request/контроллер), а внутрь передавайте типы.

Итоги

В этой статье вы построили связную модель веб‑приложения на PHP 8.0:

Эти знания станут основой для следующего уровня: архитектуры веб‑приложений (слои, контроллеры, сервисы), тестирования обработчиков и более строгой модели запросов/ответов.

Безопасность веб‑приложений на PHP

Как тема связана с предыдущими статьями

В прошлых материалах курса мы уже построили каркас современного PHP 8.0 приложения:

Безопасность соединяет всё это в одну практику: мы не просто «закрываем дыры», а проектируем приложение так, чтобы опасные данные оставались на границе, а внутри работали типизированные объекты, понятные исключения и ограниченные привилегии.

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

Модель угроз: что именно мы защищаем

Вместо списка «страшных слов» полезно держать в голове простую модель.

Хороший практический ориентир для веб‑приложений — проект OWASP Top 10.

Ссылка:

Базовое правило безопасности

if (!is_string(allowed[name = bin2hex(random_bytes(16)) . '.' . mime]; dir, '/\\') . DIRECTORY_SEPARATOR . tmp, name; } `

Документация:

Документация:

Десериализация: не используйте unserialize на недоверенных данных

unserialize() над недоверенным вводом может приводить к тяжёлым последствиям.

Безопасный базовый подход для обмена данными:

Документация:

Документация:

Минимальный чек‑лист для проектов на PHP 8.0

Итоги

В этой статье вы собрали «каркас безопасности» для веб‑приложений на PHP 8.0:

Дальше эти принципы будут применяться в более «архитектурном» виде: разделение на middleware, сервисы, политики доступа, централизованная обработка ошибок и тестирование сценариев безопасности.

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

Как эта тема связана с предыдущими статьями

Ранее в курсе мы выстроили практику современного PHP 8.0:

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

!Пирамида тестирования помогает понять, каких тестов должно быть больше

Тестирование как часть дизайна

Тесты в PHP-проекте решают три задачи:

Важно связать тестирование с тем, что уже было в курсе:

Виды тестов и что именно они проверяют

Unit-тесты

Unit-тест проверяет маленький фрагмент логики в изоляции от инфраструктуры.

Признаки хорошего unit-теста:

Идеальные кандидаты из нашего курса:

Интеграционные тесты

Интеграционный тест проверяет связку компонентов и реальную инфраструктуру или её близкий аналог.

Типичные примеры:

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

E2E-тесты

End-to-end тест проверяет сценарий как пользователь: от HTTP-запроса до ответа.

В рамках курса без фреймворка такие тесты можно делать на уровне:

Но практическая рекомендация обычно такая:

PHPUnit: базовый инструмент тестирования в PHP

Самый распространённый фреймворк для тестирования в PHP — PHPUnit.

Документация:

Минимальная установка через Composer

Обычно PHPUnit устанавливают как dev-зависимость:

Далее вы запускаете тесты:

Пример unit-тестов: проверяем инварианты и исключения

Возьмём value object Email из статьи про ООП: он гарантирует валидность и выбрасывает исключение при некорректном значении.

Класс:

Unit-тесты:

Здесь важно:

Тест-дубли: когда и как подменять зависимости

Когда класс зависит от интерфейса, вы можете подменить реализацию в тесте.

Термины:

Практический ориентир:

Пример: сервис зависит от Mailer. В тесте мы хотим проверить, что письмо отправлено.

Мы не привязываемся к конкретной библиотеке отправки писем, а тестируем поведение через интерфейс, как и требует SOLID.

Интеграционные тесты для PDO: проверяем реальное взаимодействие

Интеграционные тесты особенно полезны для репозиториев:

Практическая идея для тестов:

Если вы тестируете на MySQL, вам поможет подход:

Для транзакционных таблиц InnoDB часто удобно оборачивать каждый тест в транзакцию и делать ROLLBACK в конце.

Контрактные тесты для интерфейсов

Если у вас есть интерфейс (например, UserRepository), и несколько реализаций (PDO, in-memory, API), то полезно проверить, что все реализации ведут себя одинаково.

Идея контрактного теста:

Это напрямую продолжает принцип LSP: реализации должны быть взаимозаменяемыми.

Качество кода: стиль, статический анализ, архитектурные границы

Качество кода в PHP обычно держится на трёх слоях:

Стиль кода и форматирование

Рекомендуемый базовый стандарт для проектов — PSR-12.

Инструменты:

Практический смысл:

Статический анализ

Статический анализ проверяет код без запуска и находит:

Два популярных инструмента:

Как связать с темами курса:

Composer scripts как минимальная автоматизация качества

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

Пример идеи для composer.json:

Тогда:

CI: почему проверки должны быть в конвейере

CI (continuous integration) — это запуск тестов и проверок на сервере при каждом пуше/PR.

Польза:

Если вы используете GitHub, практический вариант — GitHub Actions.

Оптимизация производительности: сначала измеряем, потом улучшаем

Ключевой принцип

Оптимизация без измерений часто приводит к:

Правильный процесс:

!Цикл оптимизации показывает, что улучшения делаются итеративно и на основе измерений

Где обычно реальные узкие места в PHP веб-приложениях

Чаще всего тормозит не «скорость языка», а I/O:

Связь с темой PDO:

Профилирование в PHP

Профилирование — это сбор данных о том, какие функции и участки кода занимают время.

Один из самых известных инструментов в PHP — Xdebug profiler.

Практическая идея:

OPcache и настройка исполнения

OPcache кэширует байткод PHP и значительно ускоряет типичный продакшен.

Практический минимум:

Микрооптимизации: что обычно не стоит делать первым

Примеры типичных преждевременных оптимизаций:

Когда микрооптимизации оправданы:

Производительность БД в контексте PHP

Даже идеальный PHP-код будет медленным, если база работает плохо.

Минимальные практики

Наблюдаемость: логируйте то, что помогает ускорять

Для оптимизации важны данные. Полезные вещи, которые можно логировать:

При этом сохраняйте правило из темы безопасности:

Итоги

В этой статье вы собрали «инженерный контур» вокруг PHP 8.0 приложения: