User registered!
"; } else { echo "Email already exists.
"; } } else { echo "Invalid email.
"; } } ?> ``` ### Хороший подход: разделение обязанностей (Separation of Concerns) Мы отрефакторим этот код, разделив взаимодействие с базой данных (Репозиторий), правила бизнес-логики и валидации (Контроллер) и визуальное представление (Blade/Шаблон). ```php // app/Repositories/UserRepository.php declare(strict_types=1); namespace App\Repositories; use PDO; class UserRepository { private PDO $pdo; public function __construct(PDO $pdo) { $this->pdo = $pdo; } public function findByEmail(string $email): ?array { $stmt = $this->pdo->prepare("SELECT * FROM users WHERE email = :email"); $stmt->execute(['email' => $email]); return $stmt->fetch() ?: null; } public function create(string $email): bool { $stmt = $this->pdo->prepare("INSERT INTO users (email) VALUES (:email)"); return $stmt->execute(['email' => $email]); } } ``` ```php // app/Http/Controllers/RegisterController.php declare(strict_types=1); namespace App\Http\Controllers; use App\Repositories\UserRepository; use InvalidArgumentException; class RegisterController { private UserRepository $userRepository; public function __construct(UserRepository $userRepository) { $this->userRepository = $userRepository; } public function register(array $data): string { $email = $data['email'] ?? ''; if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { throw new InvalidArgumentException("Invalid email format."); } if ($this->userRepository->findByEmail($email) !== null) { return "Email already exists."; } $this->userRepository->create($email); return "User registered!"; } } ``` --- ## Божественный объект **Божественный объект (God Object)** — это монолитный класс, который знает слишком много или делает слишком много. Он концентрирует в себе всю логику приложения, нарушая **принцип единственной ответственности (SRP)**. Другие классы в системе превращаются в простые держатели данных (анемичные модели), управляемые этим гигантским классом. ### Плохой подход: монолитный OrderManager В данном примере один класс отвечает за подключение к платежному шлюзу, сохранение в базу данных, отправку писем, расчет скидок и генерацию PDF-документов. ```php // app/Services/OrderManager.php declare(strict_types=1); namespace App\Services; class OrderManager { public function processOrder(array $orderData): void { // 1. Calculate discount $total = $orderData['price']; if ($orderData['coupon'] === 'SUMMER') { $total *= 0.9; } // 2. Save order to database $db = new \PDO("mysql:host=localhost;dbname=shop", "root", ""); $stmt = $db->prepare("INSERT INTO orders (total, user_id) VALUES (?, ?)"); $stmt->execute([$total, $orderData['user_id']]); // 3. Process payment via Stripe $stripe = new \Stripe\StripeClient('sk_test_key'); $stripe->charges->create([ 'amount' => (int)($total * 100), 'currency' => 'usd', 'source' => $orderData['token'], ]); // 4. Generate PDF invoice $pdf = new \FPDF(); $pdf->AddPage(); $pdf->Write(10, "Invoice total: " . $total); $pdf->Output('F', "/invoices/order.pdf"); // 5. Send email notification mail($orderData['email'], "Order Success", "Your order total is " . $total); } } ``` ### Хороший подход: слабосвязанные сервисы Мы проводим рефакторинг, делегируя каждую задачу предметной области специализированному компоненту, превращая управляющий класс в легковесный координатор. ```php // app/Services/OrderService.php declare(strict_types=1); namespace App\Services; use App\Repositories\OrderRepository; use App\Services\Payment\PaymentGatewayInterface; use App\Services\Notification\NotificationInterface; use App\Services\Invoice\InvoiceGeneratorInterface; class OrderService { private OrderRepository $repository; private DiscountCalculator $discountCalculator; private PaymentGatewayInterface $paymentGateway; private InvoiceGeneratorInterface $invoiceGenerator; private NotificationInterface $notifier; public function __construct( OrderRepository $repository, DiscountCalculator $discountCalculator, PaymentGatewayInterface $paymentGateway, InvoiceGeneratorInterface $invoiceGenerator, NotificationInterface $notifier ) { $this->repository = $repository; $this->discountCalculator = $discountCalculator; $this->paymentGateway = $paymentGateway; $this->invoiceGenerator = $invoiceGenerator; $this->notifier = $notifier; } public function checkout(array $orderData): void { $total = $this->discountCalculator->calculate($orderData['price'], $orderData['coupon']); $order = $this->repository->save($total, $orderData['user_id']); $this->paymentGateway->charge($total, $orderData['token']); $invoicePath = $this->invoiceGenerator->generate($order); $this->notifier->sendSuccessNotification($orderData['email'], $total, $invoicePath); } } ``` --- ## Золотой молоток **Золотой молоток (Golden Hammer)** — это предположение о том, что любимая технология или паттерн проектирования применимы повсеместно: *«Если всё, что у вас есть — это молоток, то всё вокруг кажется гвоздем»* В PHP это часто происходит, когда разработчики пытаются использовать сложные структурные или поведенческие паттерны (например, Состояние или Посетитель) для простых задач, что ведет к избыточному росту количества классов, или используют базу данных (такую как Elasticsearch или Redis) для задач, которые можно легко решить напрямую средствами SQL. ### Плохой подход: навязывание паттерна «Состояние» для простой проверки возраста Разработчик хочет проверить, разрешено ли пользователю покупать алкоголь. Вместо простого условия создается целая инфраструктура паттерна «Состояние» с несколькими интерфейсами и конкретными классами. ```php // app/Validation/AgeValidator.php declare(strict_types=1); namespace App\Validation; interface AgeStateInterface { public function canPurchaseAlcohol(): bool; } class UnderageState implements AgeStateInterface { public function canPurchaseAlcohol(): bool { return false; } } class AdultState implements AgeStateInterface { public function canPurchaseAlcohol(): bool { return true; } } class AgeValidator { private AgeStateInterface $state; public function __construct(int $age) { $this->state = $age >= 18 ? new AdultState() : new UnderageState(); } public function check(): bool { return $this->state->canPurchaseAlcohol(); } } ``` ### Хороший подход: будьте проще (принцип KISS) Паттерны проектирования добавляют сложность и когнитивную нагрузку. Если бизнес-логика проста, пишите ее просто. ```php // app/Validation/AgeValidator.php declare(strict_types=1); namespace App\Validation; class AgeValidator { private const ALCOHOL_MINIMUM_AGE = 18; public static function canPurchaseAlcohol(int $age): bool { return $age >= self::ALCOHOL_MINIMUM_AGE; } } ``` > [!NOTE] > **Используйте паттерны, когда этого требует сложность**: Паттерны проектирования созданы для управления меняющимися требованиями и высокой сложностью. Если ваша логика состояний содержит лишь одно простое условие, которое никогда не изменится, применение паттерна является избыточным проектированием (over-engineering). --- ## Преждевременная оптимизация **Преждевременная оптимизация (Premature Optimization)** — это оптимизация производительности кода до того, как вы получите конкретные доказательства (с помощью инструментов профилирования, таких как Xdebug или Blackfire), что этот участок кода действительно является узким местом (bottleneck). Это приводит к нечитаемому, сложному коду, написанному ради экономии микросекунд, в то время как без внимания остаются запросы к базе данных или медленные внешние API-запросы, занимающие сотни миллисекунд. ### Плохой подход: запутанные микрооптимизации Разработчик отказывается от понятных функций PHP и использует вложенный поиск в строках и побитовые операции для разбора строк конфигурации, полагая, что это работает быстрее. ```php // app/Config/Parser.php declare(strict_types=1); namespace App\Config; class Parser { // Cryptic string manipulation to save CPU cycles public function parse(string $data): array { $pos = strpos($data, ':'); if ($pos === false) return []; $key = substr($data, 0, $pos); $val = substr($data, $pos + 1); // Bitwise flag check representing boolean configuration $isFlagged = (int)$val & 1; return [$key => (bool)$isFlagged]; } } ``` ### Хороший подход: сначала читаемость кода Пишите код, который легко читать, тестировать и поддерживать. Если производительность становится проблемой, сначала проведите профилирование, а затем оптимизируйте те места, которые действительно являются узкими местами. ```php // app/Config/Parser.php declare(strict_types=1); namespace App\Config; class Parser { public function parse(string $jsonString): array { $decoded = json_decode($jsonString, true); if (json_last_error() !== JSON_ERROR_NONE) { return []; } return $decoded; } } ``` --- ## Карго-культ и копипаст-программирование **Программирование карго-культа (Cargo Cult Programming)** — это практика копирования шаблонов кода, структур или методологий без понимания того, *почему* они используются и какую проблему решают. Классический пример в PHP — оборачивание моделей Laravel Eloquent в пустой слой репозиториев (Repository Layer), потому что «хорошая архитектура требует репозиториев», хотя Eloquent уже сам реализует паттерны Active Record и Query Builder. ### Плохой подход: пустая абстрактная обертка репозитория Этот репозиторий-обертка просто копирует методы Eloquent, не добавляя никакой абстракции или пользы, но при этом удваивает количество классов, которые необходимо поддерживать. ```php // app/Repositories/PostRepositoryInterface.php declare(strict_types=1); namespace App\Repositories; interface PostRepositoryInterface { public function find(int $id); public function create(array $data); } // app/Repositories/EloquentPostRepository.php declare(strict_types=1); namespace App\Repositories; use App\Models\Post; class EloquentPostRepository implements PostRepositoryInterface { public function find(int $id) { return Post::find($id); } public function create(array $data) { return Post::create($data); } } ``` ### Хороший подход: используйте Active Record напрямую или создавайте реальные абстракции Если ваш репозиторий не изолирует клиента от механизма хранения данных (например, всё равно возвращает «сырые» запросы или модели Eloquent), откажитесь от него и используйте Eloquent напрямую. ```php // app/Http/Controllers/PostController.php declare(strict_types=1); namespace App\Http\Controllers; use App\Models\Post; use Illuminate\Http\JsonResponse; class PostController { public function show(int $id): JsonResponse { // Use active record pattern directly $post = Post::findOrFail($id); return response()->json($post); } } ``` > [!TIP] > **Когда использовать репозитории**: Используйте их при реализации сложной доменной логики, которая должна оставаться независимой от ORM (например, в предметно-ориентированном проектировании — DDD), или при создании переиспользуемых пользовательских запросов, которые вы хотите протестировать изолированно. --- ## Частые ошибки 1. **Навязывание паттернов повсюду**: Реализация паттернов проектирования в простых CRUD-проектах. 2. **Написание классов-богов**: Позволение вспомогательному классу или менеджеру бесконечно разрастаться вместо разделения его на небольшие, специализированные сервисы. 3. **Оптимизация без профилирования**: Переписывание чистых циклов PHP в сложные алгоритмы только из-за «подозрений» в их медленной работе, в то время как база данных выполняет запросы без индексов. 4. **Слепое копирование**: Копирование продвинутых корпоративных паттернов (таких как CQRS, Event Sourcing или слои репозиториев) в простые MVC-проекты только потому, что они популярны в интернете. --- ## Чек-лист 1. **Проверка SRP:** Есть ли у вашего класса более одной причины для изменения? Если да, разделите его. 2. **Принцип KISS:** Может ли простое условие `if` или вспомогательная функция заменить сложную ООП-иерархию? 3. **Профилирование производительности:** Выполняли ли вы профилирование вашего приложения с помощью Xdebug или Blackfire перед применением микрооптимизаций? 4. **Полезная абстракция:** Действительно ли ваш репозиторий или слой абстракции скрывает детали реализации, или это просто избыточная обертка? --- ## Заключение Антипаттерны проектирования — это распространенные ловушки, которые приводят к созданию жесткого и хрупкого программного обеспечения. **Спагетти-код** возникает из-за отсутствия разделения обязанностей. **Божественные объекты** объединяют слишком много обязанностей. **Золотой молоток** навязывает неверные решения для проблем. **Преждевременная оптимизация** ставит микропроизводительность выше читаемости. **Карго-культ** дублирует структуры без понимания их архитектурной ценности. Держите код простым, понятным и добавляйте паттерны проектирования только тогда, когда этого требует сложность. --- ## Тест для самопроверки ### Вопрос 1: Какой принцип SOLID напрямую нарушается, когда класс выступает в роли «Божественного объекта» (God Object)? - A) Open/Closed Principle (OCP) - B) Liskov Substitution Principle (LSP) - C) Single Responsibility Principle (SRP)