User registered!
"; } else { echo "Email already exists.
"; } } else { echo "Invalid email.
"; } } ?> ``` ### Добрият начин: Разделяне на отговорностите (Separation of Concerns) Рефакторираме това, като разделим взаимодействието с базата данни (Repository), бизнес/валидационните правила (Controller) и визуалното представяне (Blade/Template). ```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!"; } } ``` --- ## Божественият обект (The God Object) **Божественият обект (God Object)** е монолитен клас, който знае твърде много или прави твърде много. Той концентрира цялата логика на приложението в себе си, нарушавайки **принципа за единствена отговорност (SRP)**. Останалите класове в системата се превръщат в прости контейнери за данни (анемични модели / anemic models), контролирани от този огромен клас. ### Лошият начин: Монолитен OrderManager Тук един-единствен клас се занимава с връзката с платежния шлюз (payment gateway), записването в базата данни, изпращането на имейли, изчисляването на отстъпки и генерирането на 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); } } ``` ### Добрият начин: Разделени услуги (Decoupled Services) Рефакторираме чрез делегиране на всяка домейн задача на специализиран компонент, оставяйки класа мениджър като лек координатор. ```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); } } ``` --- ## Златният чук (The Golden Hammer) **Златният чук (Golden Hammer)** е предположението, че любима технология или шаблон за дизайн е универсално приложим: *„Ако единственото нещо, което имате, е чук, всичко ви изглежда като пирон.“* В PHP това често се случва, когато разработчиците се опитват да използват сложни структурни или поведенчески шаблони (например State или Visitor) за прости задачи, което води до ненужно пренасищане с класове (class explosion), или когато използват база данни (като Elasticsearch или Redis) за задачи, които лесно могат да бъдат изпълнени директно в SQL. ### Лошият начин: Налагане на шаблона State за проста проверка на възрастта Разработчик иска да провери дали на даден потребител е разрешено да купува алкохол. Вместо обикновено условно условие, той изгражда цяла архитектура по шаблона State с множество интерфейси и конкретни класове. ```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) **Преждевременната оптимизация (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; } } ``` --- ## Карго култ и Copy-Paste програмиране (Cargo Cult & Copy-Paste Programming) **Програмирането тип „карго култ“ (Cargo Cult Programming)** е практиката да се копират кодови шаблони, структури или методологии, без да се разбира *защо* се използват или какъв проблем решават. Класически пример в PHP е обвиването (wrapping) на Laravel Eloquent модели в празен слой от хранилища (Repository Layer), защото „добрата архитектура изисква repositories“, въпреки че Eloquent вече имплементира шаблоните Active Record и Query Builder. ### Лошият начин: Празна обвивка (Wrapper) за абстракция на Repository Това обвиващо хранилище (wrapper repository) просто копира методите на 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 директно или създайте реални абстракции Ако вашето хранилище (repository) не изолира клиента от механизма за съхранение (например ако така или иначе връща чисти 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] > **Кога да използвате repositories**: Използвайте ги, когато имплементирате сложна бизнес логика (domain logic), която трябва да остане независима от ORM-а (например при Domain-Driven Design), или когато изграждате персонализирани заявки за многократна употреба, които искате да тествате изолирано. --- ## Често срещани грешки 1. **Налагане на шаблони навсякъде (Forcing Patterns Everywhere)**: Внедряване на шаблони за дизайн в прости CRUD проекти. 2. **Писане на класове тип „божество“ (Writing God Classes)**: Допускане помощен или мениджърски клас да расте безкрайно, вместо да бъде разделен на малки, тясно специализирани услуги. 3. **Оптимизиране без профилиране (Optimizing without Profiling)**: Пренаписване на чисти PHP цикли в сложни алгоритми, само защото „подозирате“, че са бавни, докато базата данни изпълнява неиндексирани заявки. 4. **Сляпо копиране (Blind Copying)**: Копиране на сложни корпоративни архитектурни модели (като CQRS, Event Sourcing или слоеве от хранилища) в прости MVC проекти, само защото са популярни в интернет. --- ## Контролен списък (Checklist) 1. **Проверка за SRP:** Има ли вашият клас повече от една причина за промяна? Ако е така, го разделете. 2. **Принцип KISS:** Може ли просто `if` условие или помощна функция да замени сложна ООП йерархия? 3. **Профилиране на производителността:** Профилирали ли сте приложението си с Xdebug или Blackfire, преди да прилагате микрооптимизации? 4. **Абстракция с добавена стойност:** Дали вашето хранилище (repository) или слой на абстракция действително скрива детайлите по имплементацията, или е просто излишен wrapper? --- ## Резюме Антипатерните за дизайн са често срещани капани, които водят до твърд и лесно чуплив софтуер. **Спагети кодът (Spaghetti Code)** възниква поради липса на разделение на отговорностите. **Божествените обекти (God Objects)** консолидират твърде много роли на едно място. **Златният чук (Golden Hammer)** налага погрешни решения за различни проблеми. **Преждевременната оптимизация (Premature Optimization)** дава приоритет на микропроизводителността пред четимостта. **Карго култът (Cargo Culting)** дублира структури, без да разбира тяхната архитектурна стойност. Поддържайте кода си прост, ясен и добавяйте шаблони за дизайн само когато сложността го изисква. --- ## Тест за самоподготовка ### Въпрос 1: Кой SOLID принцип се нарушава директно, когато даден клас действа като „Божествен обект“ (God Object)? - A) Принципът за отвореност/затвореност (OCP) - B) Принципът за заместване на Лисков (LSP) - C) Принципът за единствена отговорност (SRP)