Design Patterns في المشاريع الحقيقية

Design Patternsتصبح ذات قيمة حقيقية عندما يفهم المطورون كيفية استخدامها في مشاريع برمجية حقيقية. تعد أنماط التعلم بشكل فردي أمرًا مهمًا، لكن تطوير البرمجيات الاحترافية يتطلب معرفة متى يتم استخدام كل نمط، وكيفية عمل الأنماط معًا، ومتى لا يتم استخدامها.

في التطبيقات الحقيقية، غالبًا ما تظهر أنماط مثل Repository، وService Layer، وDTO، وFactory، وStrategy، وAdapter، وDecorator، وObserver، وCommand، وFacade، وDependency Injection معًا. فهي تساعد المطورين على إنشاء برامج نظيفة ومرنة وقابلة للصيانة وأسهل في الاختبار.

مقدمة

خلال سلسلة OOP وDesign Patterns، ناقشنا العديد من الأنماط والمفاهيم المهمة. قمنا بتغطية أساسيات البرمجة كائنية التوجه، وinheritance، وencapsulation، وpolymorphism، وabstraction، وinterfaces، والأساليب الثابتة، ومساحات الأسماء، والتحميل التلقائي، وأفضل ممارسات OOP، والعديد من Design Patterns.

ومع ذلك، فإن تعلم Design Patterns واحدًا تلو الآخر ليس سوى الخطوة الأولى. الخطوة الأكثر أهمية هي فهم كيفية تطبيقها في مشاريع حقيقية دون المبالغة في هندسة الكود.

تركز هذه المقالة على الاستخدام العملي. وهو يشرح كيفية ظهور Design Patterns في التطبيقات الحقيقية، وكيف تدعم سير العمل المشترك، وكيف يمكن للمطورين اختيار النمط الصحيح بناءً على المشكلة التي يقومون بحلها.

لماذا Design Patterns مهم في المشاريع الحقيقية

Design Patterns مهمة لأن المشاريع الحقيقية تتغير بمرور الوقت. تتغير المتطلبات، وتتم إضافة ميزات جديدة، ويتم استبدال الخدمات الخارجية، وتصبح قواعد العمل أكثر تعقيدًا، وتنمو الفرق.

بدون بنية جيدة، يمكن أن يصبح المشروع صعب الصيانة بسرعة. تصبح وحدات التحكم كبيرة جدًا، وتصبح الخدمات فوضوية، وتتكرر استعلامات database، وينتشر رمز API الخارجي في كل مكان، وتؤدي التغييرات الصغيرة إلى إنشاء أخطاء غير متوقعة.

توفر Design Patterns طرقًا مجربة لتنظيم الكود. إنها تساعد المطورين على فصل المسؤوليات، وتقليل الازدواجية، والاعتماد على التجريدات، وتسهيل توسيع الكود.

Design Patterns ليست سحرية

Design Patterns ليست حلولاً سحرية. فهي لا تجعل الكود نظيفة تلقائيًا. النمط المستخدم في المكان الخطأ يمكن أن يجعل الكود أكثر تعقيدًا.

الهدف هو عدم استخدام أكبر عدد ممكن من الأنماط. الهدف هو حل مشاكل التصميم الحقيقية ببنية بسيطة ومناسبة.

المطور الجيد لا يسأل: "ما النمط الذي يمكنني فرضه هنا؟" يسأل المطور الجيد: "ما هي المشكلة التي أواجهها، وما هو أسلوب التصميم الذي يجعل الكود أكثر وضوحًا؟"

مشاكل المشروع الحقيقية الشائعة التي تم حلها بواسطة Design Patterns

تعد Design Patterns مفيدة لأنها تحل مشاكل البرامج الشائعة التي تظهر بشكل متكرر في المشاريع الحقيقية.

تشمل المشاكل الشائعة ما يلي:

  • أصبحت وحدات التحكم كبيرة جدًا.

  • يتم تكرار منطق العمل في العديد من الأماكن.

  • يتم خلط استعلامات قاعدة البيانات مع الخدمات وcontrollers.

  • تفاصيل API الخارجية المنتشرة عبر قاعدة الكود.

  • هناك عدد كبير جدًا من عبارات if والتبديل لسلوكيات مختلفة.

  • classes يصعب اختباره مع التبعيات المخفية.

  • مسارات العمل المعقدة التي تحتاج إلى events أو الوظائف أو commands.

  • classes كبير يقوم بأشياء كثيرة جدًا.

يمكن أن يساعد كل نمط تصميم في حل واحدة أو أكثر من هذه المشكلات عند استخدامه بشكل صحيح.

مثال حقيقي للمشروع: تسجيل المستخدم

يعد تسجيل المستخدم ميزة شائعة في كل تطبيقات الويب تقريبًا. قد تبدأ ميزة التسجيل البسيطة بإنشاء سجل مستخدم. لاحقًا، قد يتضمن ذلك validation، وتجزئة كلمة المرور، وإنشاء الملف الشخصي، والبريد الإلكتروني الترحيبي، والتحقق من البريد الإلكتروني، وتسجيل التدقيق، والتحليلات، وإخطار المسؤول.

يمكن أن تعمل عدة أنماط معًا في هذه الميزة:

  • DTO Pattern:يحمل بيانات التسجيل التحقق من صحتها.

  • Service Layer Pattern:ينظم سير عمل التسجيل.

  • Repository Pattern:يعالج الوصول إلى بيانات المستخدم.

  • Dependency Injection:يوفر تبعيات للخدمة.

  • Observer Pattern:يسمح لـ listeners بالتفاعل بعد التسجيل.

  • Command Pattern:يمكن أن يمثل التسجيل كـ command في الأنظمة الأكبر.

والنتيجة هي تدفق تسجيل أنظف وأكثر قابلية للصيانة.

مثال على تسجيل المستخدم في PHP

readonly class RegisterUserDto
{
    public function __construct(
        public string $name,
        public string $email,
        public string $password
    ) {
    }
}

class UserRegistrationService
{
    public function __construct(
        private UserRepositoryInterface $users,
        private PasswordHasher $passwordHasher,
        private EventDispatcherInterface $events
    ) {
    }

    public function register(RegisterUserDto $dto): User
    {
        if ($this->users->findByEmail($dto->email)) {
            throw new RuntimeException('Email already exists.');
        }

        $user = $this->users->create([
            'name' => $dto->name,
            'email' => $dto->email,
            'password' => $this->passwordHasher->hash($dto->password),
        ]);

        $this->events->dispatch(new UserRegistered($user));

        return $user;
    }
}

يستخدم هذا المثال الإرسال DTO وService Layer وRepository وDependency Injection وevent بObserver Pattern. ولكل جزء مسؤولية واضحة.

مثال حقيقي للمشروع: الخروج من التجارة الإلكترونية

يعد Checkout ميزة أكثر تعقيدًا في العالم الحقيقي. قد تتضمن عربة التسوق validation، وحساب الخصم، وحساب تكلفة الشحن، ومعالجة الدفع، وإنشاء الطلب، وتحديث المخزون، وإنشاء الفاتورة، وتأكيد البريد الإلكتروني، وتتبع التحليلات.

يمكن أن تدعم العديد من Design Patterns سير العمل هذا:

  • Service Layer:ينسق عملية الخروج.

  • Strategy Pattern:يتعامل مع طرق الدفع أو قواعد الشحن أو قواعد الخصم.

  • Factory Pattern:إنشاء استراتيجية الدفع أو الشحن الصحيحة.

  • Repository Pattern:يخزن الطلبات ويستعيد المنتجات.

  • Adapter Pattern:يتصل ببوابات الدفع الخارجية.

  • Observer Pattern:يثير الآثار الجانبية بعد وضع الطلب.

  • Command Pattern:قوائم الانتظار بطيئة المهام مثل البريد الإلكتروني أو إنشاء الفاتورة.

يسمح هذا المزيج لمنطق الخروج بالبقاء منظمًا بدلاً من أن يصبح طريقة controller ضخمة.

مثال على خدمة الخروج

class CheckoutService
{
    public function __construct(
        private CartValidator $cartValidator,
        private DiscountStrategy $discountStrategy,
        private PaymentGatewayInterface $paymentGateway,
        private OrderRepositoryInterface $orders,
        private InventoryService $inventory,
        private EventDispatcherInterface $events
    ) {
    }

    public function checkout(User $user, Cart $cart): Order
    {
        $this->cartValidator->validate($cart);

        $discount = $this->discountStrategy->calculate($cart);

        $order = $this->orders->createFromCart($user, $cart, $discount);

        $this->paymentGateway->charge($order);
        $this->inventory->decreaseStock($cart);

        $this->events->dispatch(new OrderPlaced($order));

        return $order;
    }
}

تقوم هذه الخدمة بتنسيق سير العمل الرئيسي. يتم فصل الدفع والخصم والمخزون ومعالجة event إلى مكوناتها الخاصة.

مثال حقيقي للمشروع: تكامل بوابة الدفع

يعد تكامل بوابة الدفع مجالًا مشتركًا حيث تكون Design Patterns مفيدة جدًا. قد يكون لدى موفري الخدمة المختلفين، مثل Stripe أو PayPal أو التحويل البنكي أو أنظمة الدفع المحلية، تنسيقات APIs وresponse مختلفة.

تشمل الأنماط المفيدة ما يلي:

  • Adapter Pattern:يحول APIs الخاص بموفر الخدمة إلى interface داخلي مشترك.

  • Strategy Pattern:يسمح باختيار طرق الدفع المختلفة.

  • Factory Pattern:إنشاء استراتيجية الدفع الصحيحة أو المحول.

  • DTO Pattern:توحيد بيانات الدفع request وresponse.

  • Dependency Injection:يحقن تنفيذ الدفع المحدد.

يؤدي هذا إلى إبعاد تفاصيل موفر الدفع عن منطق التطبيق الأساسي.

interface الدفع ومثال DTO

readonly class PaymentRequestDto
{
    public function __construct(
        public float $amount,
        public string $currency,
        public string $customerEmail
    ) {
    }
}

readonly class PaymentResultDto
{
    public function __construct(
        public bool $successful,
        public ?string $transactionId,
        public ?string $message = null
    ) {
    }
}

interface PaymentGatewayInterface
{
    public function charge(PaymentRequestDto $request): PaymentResultDto;
}

يعتمد التطبيق الآن على تنسيقات interface وDTOs الداخلية المستقرة بدلاً من الاعتماد بشكل مباشر على تنسيقات request وresponse الخاصة بموفر الخدمة.

مثال محول الدفع

class StripePaymentAdapter implements PaymentGatewayInterface
{
    public function __construct(
        private StripeClient $client
    ) {
    }

    public function charge(PaymentRequestDto $request): PaymentResultDto
    {
        $response = $this->client->createCharge([
            'amount' => $request->amount,
            'currency' => $request->currency,
            'email' => $request->customerEmail,
        ]);

        return new PaymentResultDto(
            successful: $response['status'] === 'paid',
            transactionId: $response['id'] ?? null,
            message: $response['message'] ?? null
        );
    }
}

يعزل هذا المحول المنطق الخاص بالشريط. إذا أضاف التطبيق لاحقًا موفر دفع آخر، فيمكن لمحول جديد تنفيذ نفس interface.

مثال حقيقي للمشروع: نظام الإخطار

قد يرسل نظام الإشعارات رسائل عبر البريد الإلكتروني أو الرسائل القصيرة أو الإشعارات الفورية أو Telegram أو Slack أو WhatsApp. قد يكون لكل قناة API مختلف.

تشمل الأنماط المفيدة ما يلي:

  • Strategy Pattern:يختار قناة الإخطار.

  • Adapter Pattern:يدمج مقدمي الخدمات الخارجيين.

  • Factory Pattern:إنشاء المرسل الصحيح.

  • Decorator Pattern:يضيف التسجيل أو إعادة المحاولة أو تحديد المعدل.

  • Command Pattern:إرسال إشعار قوائم الانتظار.

  • Observer Pattern:يرسل الإخطارات بعد events.

يتيح ذلك للتطبيق إضافة قنوات جديدة دون إعادة كتابة سير عمل الإشعارات.

مثال على استراتيجية الإخطار

interface NotificationSender
{
    public function send(string $recipient, string $message): bool;
}

class EmailNotificationSender implements NotificationSender
{
    public function send(string $recipient, string $message): bool
    {
        // Send email
        return true;
    }
}

class SmsNotificationSender implements NotificationSender
{
    public function send(string $recipient, string $message): bool
    {
        // Send SMS
        return true;
    }
}

يمكن للتطبيق استخدام NotificationSender دون معرفة قناة concrete.

الديكور في نظام الإخطار الحقيقي

يمكن إضافة التسجيل دون تغيير المرسل الأصلي:

class LoggedNotificationSender implements NotificationSender
{
    public function __construct(
        private NotificationSender $sender,
        private LoggerInterface $logger
    ) {
    }

    public function send(string $recipient, string $message): bool
    {
        $this->logger->info('Sending notification', [
            'recipient' => $recipient,
        ]);

        return $this->sender->send($recipient, $message);
    }
}

يعد هذا استخدامًا عمليًا لـ Decorator Pattern في المشاريع الحقيقية.

مثال حقيقي للمشروع: إنشاء التقارير

يتضمن إنشاء التقارير غالبًا استرجاع البيانات وتصفيتها وتنسيقها وتصديرها وتخزينها وإخطارها. قد يدعم تنسيقات متعددة مثل PDF وExcel وCSV وJSON.

تشمل الأنماط المفيدة ما يلي:

  • Repository Pattern:يستعيد بيانات التقرير.

  • Service Layer:إحداثيات إنشاء التقرير.

  • Strategy Pattern:يختار تنسيق التصدير.

  • Factory Pattern:إنشاء المصدر الصحيح.

  • Command Pattern:قوائم الانتظار طويلة الأمد لإنشاء التقارير.

  • Facade Pattern:يوفر interface بسيطًا لسير عمل التقارير المعقدة.

تساعد هذه البنية في الحفاظ على سهولة إدارة إنشاء التقارير عند إضافة تنسيقات وعوامل تصفية جديدة.

مثال على استراتيجية التصدير

interface ReportExporter
{
    public function export(array $data): string;
}

class PdfReportExporter implements ReportExporter
{
    public function export(array $data): string
    {
        return 'PDF content';
    }
}

class CsvReportExporter implements ReportExporter
{
    public function export(array $data): string
    {
        return 'CSV content';
    }
}

يتم تنفيذ كل تنسيق تصدير كإستراتيجية منفصلة. يمكن لخدمة التقرير استخدام أي مصدر من خلال نفس interface.

مثال حقيقي للمشروع: نظام استيراد الملفات

غالبًا ما تحتاج أنظمة استيراد الملفات إلى validation، والتحليل، ورسم الخرائط، والتحقق من التكرارات، وحفظ database، والإبلاغ عن الأخطاء، ومعالجة الخلفية.

تشمل الأنماط المفيدة ما يلي:

  • Strategy Pattern:يحدد نوع المحلل اللغوي مثل CSV، أو Excel، أو JSON.

  • DTO Pattern:يمثل الصفوف المستوردة.

  • Repository Pattern:يحفظ البيانات المستوردة.

  • Service Layer:ينسق سير عمل الاستيراد.

  • Command Pattern:يقوم بتشغيل الاستيراد كمهمة في قائمة الانتظار.

  • Observer Pattern:مشغلات الإخطارات بعد الانتهاء من الاستيراد.

وهذا يمنع منطق استيراد الملف من أن يصبح class واحدًا كبيرًا.

مثال على استراتيجية محلل الملفات

interface FileParser
{
    public function parse(string $filePath): array;
}

class CsvFileParser implements FileParser
{
    public function parse(string $filePath): array
    {
        // Parse CSV file
        return [];
    }
}

class JsonFileParser implements FileParser
{
    public function parse(string $filePath): array
    {
        // Parse JSON file
        return [];
    }
}

يمكن لخدمة الاستيراد استخدام المحلل اللغوي interface ولا تحتاج إلى معرفة تفاصيل كل تنسيق ملف.

مثال حقيقي للمشروع: تطبيق متعدد المستأجرين

غالبًا ما تخدم التطبيقات متعددة المستأجرين العديد من العملاء أو المؤسسات من نفس التطبيق. وقد يحتاجون إلى إعدادات خاصة بالمستأجر، ومسارات التخزين، وموفري الدفع، والعلامات التجارية، والأذونات، وعوامل تصفية البيانات.

تشمل الأنماط المفيدة ما يلي:

  • Strategy Pattern:يختار السلوك الخاص بالمستأجر.

  • Factory Pattern:إنشاء خدمات خاصة بالمستأجر.

  • Repository Pattern:يطبق تصفية بيانات المستأجر.

  • Decorator Pattern:يضيف نطاق المستأجر أو التسجيل.

  • Dependency Injection:يوفر خدمات علم المستأجر.

تساعد Design Patterns في الحفاظ على تنظيم منطق المستأجر ومنع شروط المستأجر من الانتشار في كل مكان.

اختيار النمط الصحيح

يبدأ اختيار النمط الصحيح بفهم المشكلة. لا تبدأ باختيار النمط. ابدأ بتحديد ما يجعل الكود صعبة.

الأسئلة المفيدة تشمل:

  • هل أصبح إنشاء الكائنات معقدًا؟ فكر في المصنع، أو المصنع المجرد، أو المنشئ، أو النموذج الأولي.

  • هل interfaces غير متوافق؟ النظر في المحول.

  • هل تحتاج إلى إضافة سلوك دون تعديل class؟ خذ بعين الاعتبار مصمم الديكور.

  • هل النظام الفرعي معقد للغاية بحيث لا يمكن استخدامه مباشرة؟ النظر في الinterface.

  • هل هناك خوارزميات أو سلوكيات متعددة؟ النظر في الاستراتيجية.

  • هل يجب أن يتفاعل العديد من listeners مع event؟ النظر في المراقب.

  • هل يجب وضع الإجراءات في قائمة الانتظار أو تسجيلها أو التراجع عنها؟ النظر في الأمر.

  • هل منطق الوصول إلى البيانات مبعثر؟ النظر في المستودع.

  • هل منطق العمل موجود داخل controllers؟ خذ بعين الاعتبار Service Layer.

  • هل المصفوفات الأولية غير واضحة؟ خذ بعين الاعتبار DTO.

يجب أن يتطابق النمط مع المشكلة.

كيف تعمل الأنماط معًا

في المشاريع الحقيقية، نادرا ما تستخدم الأنماط وحدها. غالبًا ما يعملون معًا بشكل طبيعي.

على سبيل المثال، قد تستخدم خدمة CheckoutService interface PaymentGatewayInterface التي يتم إدخالها من خلال Dependency Injection. قد تكون بوابة الدفع عبارة عن محول حول Stripe. يمكن اختيار طريقة الدفع المحددة باستخدام الإستراتيجية. يمكن إنشاء الإستراتيجية الصحيحة بواسطة المصنع. قد يقوم OrderPlaced النهائي event بإخطار المراقبين. قد يتم وضع SendInvoiceCommand في قائمة الانتظار بعد تقديم الطلب.

هذا لا يعني أن المشروع قد تمت هندسته بشكل مبالغ فيه إذا كان كل نمط يحل مشكلة حقيقية. المفتاح هو أن كل class يتحمل مسؤولية واضحة ويظل الرمز مفهومًا.

مثال: الأنماط التي تعمل معًا

class CheckoutService
{
    public function __construct(
        private OrderRepositoryInterface $orders,
        private PaymentGatewayInterface $paymentGateway,
        private DiscountStrategy $discountStrategy,
        private EventDispatcherInterface $events
    ) {
    }

    public function checkout(CreateOrderDto $dto): Order
    {
        $discount = $this->discountStrategy->calculate($dto);

        $order = $this->orders->create($dto, $discount);

        $this->paymentGateway->charge(
            new PaymentRequestDto(
                amount: $order->total,
                currency: $order->currency,
                customerEmail: $order->customerEmail
            )
        );

        $this->events->dispatch(new OrderPlaced($order));

        return $order;
    }
}

يجمع هذا المثال بين Service Layer وRepository وStrategy وPaymentGateway بAdapter Pattern وDTO وDependency Injection وObserver. يبقى الكود مفهوما لأن كل تبعية لها دور واضح.

Design Patterns في مشاريع Laravel

يوفر Laravel العديد من الأدوات التي تجعل Design Patterns أسهل في التطبيق. تدعم حاوية الخدمة الخاصة بها Dependency Injection. تدعم الأحداث وlisteners بنية Observer Pattern. تدعم الوظائف العمل في الخلفية بنمط الأوامر. بإمكان Eloquent العمل مع Repository Pattern عند الحاجة. خدمة classes والإجراء classes يمكنها تنظيم منطق العمل.

يتضمن الاستخدام الشائع لنمط Laravel ما يلي:

  • خدمة classes لسير عمل الأعمال.

  • طلبات النموذج لـ validation.

  • DTOs لإدخال الخدمة المنظمة.

  • مستودعات للوصول إلى البيانات المعقدة.

  • الأحداث وlisteners للآثار الجانبية.

  • وظائف لـ commands في قائمة الانتظار.

  • محولات APIs خارجية.

  • استراتيجيات الدفع أو الشحن أو الخصومات أو الصادرات.

لا يفرض Laravel كل الأنماط، لذلك يجب على المطورين استخدامها بناءً على مدى تعقيد المشروع.

Design Patterns في مشاريع Symfony

يدعم Symfony بقوة البنية الموجهة نحو الخدمة وDependency Injection. تستخدم العديد من تطبيقات Symfony الخدمات بشكل طبيعي، ومشتركي repositories، ومشتركي event، ومعالجات command، وDTOs، والمحولات، والاستراتيجيات.

يتضمن الاستخدام الشائع لنمط Symfony ما يلي:

  • خدمات منطق التطبيق.

  • عقيدة repositories للوصول إلى البيانات.

  • مرسل الحدث لسلوك Observer Pattern.

  • مكون Messenger لسير العمل بنمط الأوامر وCQRS.

  • DTOs للنماذج، APIs، وcommands.

  • محولات للخدمات الخارجية.

  • الخدمات الموسومة للاستراتيجية collections.

هيكل Symfony يجعله مناسبًا للمشاريع الكبيرة حيث تساعد الأنماط في الحفاظ على تنظيم الكود.

Design Patterns والهندسة المعمارية النظيفة

تدعم Design Patterns clean architecture من خلال المساعدة في فصل الاهتمامات. تركز البنية النظيفة على إبقاء قواعد العمل مستقلة عن أطر العمل، databases، وواجهة المستخدمs، والخدمات الخارجية.

يمكن للأنماط أن تدعم هذا الهدف:

  • يقوم مستودع interfaces بحماية منطق العمل من تفاصيل database.

  • محولات عزل الخدمات الخارجية.

  • يحدد DTOs حدود نقل البيانات.

  • تنظم الخدمات أو حالات الاستخدام سير عمل التطبيق.

  • يوفر Dependency Injection تطبيقات من الخارج.

  • تمثل الأوامر إجراءات التطبيق.

  • الأحداث والمراقبون يفصلون الآثار الجانبية.

ومع ذلك، clean architecture لا يتطلب استخدام كل نمط. يتطلب حدودًا واضحة واتجاهًا جيدًا للتبعية.

Design Patterns والمبادئ الصلبة

ترتبط Design Patterns ومبادئ SOLID ارتباطًا وثيقًا. تساعد العديد من الأنماط في تطبيق مبادئ SOLID في الكود العملية.

على سبيل المثال:

  • يدعم Strategy Pattern المبدأ المفتوح المغلق.

  • يدعم Dependency Injection مبدأ انعكاس التبعية.

  • يساعد Service Layer في دعم مبدأ المسؤولية الفردية.

  • يدعم Adapter Pattern التصميم المستند إلى interface.

  • يقوم Decorator Pattern بتوسيع السلوك دون تعديل classes الموجود.

  • Repository Pattern يفصل بين مخاوف الاستمرارية.

يساعد فهم SOLID المطورين على استخدام Design Patterns بشكل أكثر حكمة.

الهندسة المفرطة مع Design Patterns

تحدث الهندسة الزائدة عندما يضيف المطورون الكثير من البنية لمشكلة لا تحتاج إليها. وهذا يمكن أن يجعل قراءة الكود أكثر صعوبة وأبطأ في التطوير.

على سبيل المثال، قد لا يحتاج نموذج الاتصال البسيط إلى DTOs وrepositories والمصانع والاستراتيجيات وcommands وevents. قد يكون controller والخدمة البسيطة كافيين.

يجب إضافة الأنماط عندما تحل مشكلة حقيقية. إذا كان النمط يضيف ملفات إضافية فقط دون تحسين الوضوح، فقد لا يكون ذلك ضروريًا.

علامات تشير إلى الإفراط في استخدام Design Patterns

قد يتم الإفراط في استخدام Design Patterns عندما:

  • تتطلب الميزات البسيطة عددًا كبيرًا جدًا من classes.

  • لا يمكن للمطورين تتبع تدفق التنفيذ بسهولة.

  • يقوم معظم classes بإعادة توجيه المكالمات فقط دون إضافة قيمة.

  • يتم إنشاء interfaces لكل class دون الحاجة إلى تطبيقات متعددة أو اختبار.

  • يبدو الرمز أكثر abstract ولكن ليس أكثر قابلية للفهم.

  • تتطلب إضافة ميزة صغيرة تحرير العديد من الطبقات غير الضرورية.

يجب أن تعمل الهندسة المعمارية الجيدة على تبسيط التغيير، وليس جعل كل تغيير أثقل.

الهندسة التحتية: المشكلة المعاكسة

يحدث نقص الهندسة عندما لا يكون هناك هيكل كافٍ. يتم وضع كل شيء في controllers أو models أو ملفات مساعدة. قد يبدو هذا سريعًا في البداية، لكنه يصبح مكلفًا لاحقًا.

تشمل علامات نقص الهندسة ما يلي:

  • controllers كبير جدًا.

  • استعلامات database المتكررة.

  • تكرار منطق العمل.

  • تنتشر مكالمات API الخارجية في كل مكان.

  • عبارات if والتبديل الطويلة لاختيار السلوك.

  • من الصعب اختبار classes.

  • التغييرات في ميزة واحدة تؤدي إلى كسر الميزات غير ذات الصلة.

الهدف هو التوازن. استخدم بنية كافية للحفاظ على المشروع قابلاً للصيانة، ولكن ليس لدرجة أن العمل البسيط يصبح معقدًا.

القاعدة العملية: ابدأ بالبساطة، ثم أعد التعامل مع الأنماط

يتمثل النهج العملي في البدء بشكل بسيط وإعادة التعامل مع الأنماط عندما تصبح الحاجة واضحة.

على سبيل المثال:

  • إذا أصبح controller كبيرًا جدًا، فقم بنقل المنطق إلى الخدمة.

  • إذا تكررت الاستعلامات، قم بإنشاء أسلوب repository.

  • إذا أصبحت المصفوفات الأولية مربكة، فقم بتقديم DTO.

  • إذا اختار العديد من العبارات السلوك، فقم بتقديم الإستراتيجية.

  • في حالة انتشار كود API الخارجي، قم بتقديم محول.

  • إذا زادت الآثار الجانبية بعد الإجراء، قم بتقديم events والمراقبين.

  • إذا كانت المهام بحاجة إلى التشغيل لاحقًا، فقم بتقديم commands أو المهام.

هذا النهج يحافظ على الهندسة المعمارية عملية ويتجنب التعقيد غير الضروري.

مثال على بنية المجلد

قد يقوم مشروع PHP أو Laravel الحقيقي بتنظيم الأنماط باستخدام مجلدات مثل:

app/
  DTO/
    CreateOrderDto.php
    PaymentRequestDto.php

  Services/
    CheckoutService.php
    UserRegistrationService.php

  Repositories/
    OrderRepositoryInterface.php
    EloquentOrderRepository.php

  Strategies/
    Discounts/
      DiscountStrategy.php
      PremiumCustomerDiscountStrategy.php
      SeasonalDiscountStrategy.php

  Adapters/
    Payments/
      StripePaymentAdapter.php
      PayPalPaymentAdapter.php

  Events/
    OrderPlaced.php

  Listeners/
    SendOrderConfirmation.php
    UpdateAnalytics.php

  Jobs/
    GenerateInvoiceJob.php

هذا مجرد مثال. يعتمد أفضل هيكل للمجلد على إطار العمل ونمط الفريق وحجم المشروع.

اختبار Design Patterns في المشاريع الحقيقية

غالبًا ما تجعل Design Patterns الاختبار أسهل. يمكن اختبار الخدمات باستخدام repositories المزيف. يمكن اختبار الاستراتيجيات بشكل مستقل. يمكن الاستهزاء بالمحولات. يمكن اختبار الأوامر كإجراءات فردية. DTOs يجعل بيانات الإدخال قابلة للتنبؤ بها.

على سبيل المثال، يعد اختبار استراتيجية الخصم أمرًا بسيطًا لأن class لديه مسؤولية واحدة مركزة:

class PremiumCustomerDiscountStrategyTest
{
    public function test_it_calculates_premium_discount(): void
    {
        $strategy = new PremiumCustomerDiscountStrategy();

        $discount = $strategy->calculate(200);

        assert($discount === 30.0);
    }
}

عادةً ما يكون اختبار classes الصغير المركز أسهل من اختبار classes المختلط الكبير.

Design Patterns وتعاون الفريق

تعمل Design Patterns أيضًا على تحسين التواصل بين المطورين. عندما يقول أحد المطورين "يجب أن يكون هذا محولاً"، يفهم المطورون الآخرون أن class يجب أن يترجم interface خارجي إلى interface داخلي.

عندما يقول أحد المطورين "استخدم إستراتيجية هنا"، يفهم الفريق أن هناك سلوكيات متعددة قابلة للتبديل.

تعمل مفردات النمط المشتركة على تسهيل مراجعة الكود ومناقشات التصميم والإعداد.

الأخطاء الشائعة في المشاريع الحقيقية

أحد الأخطاء الشائعة هو استخدام الأنماط لأنها تبدو احترافية، وليس لأنها تحل مشكلة حقيقية.

خطأ آخر هو الخلط بين المسؤوليات حتى أثناء استخدام الأنماط. على سبيل المثال، يجب ألا يحتوي repository على منطق سير عمل الأعمال، ويجب ألا يحتوي DTO على قواعد عمل معقدة.

الخطأ الثالث هو إنشاء interfaces لكل شيء بدون سبب. تكون الinterfaces مفيدة عندما تكون هناك تطبيقات متعددة، أو احتياجات اختبار، أو حدود معمارية.

الخطأ الرابع هو تجاهل الاتفاقيات الإطارية. توفر Laravel وSymfony وأطر العمل الأخرى بالفعل هياكل مفيدة. يجب أن تعمل الأنماط مع الإطار وليس ضده.

أفضل الممارسات لاستخدام Design Patterns في المشاريع الحقيقية

لاستخدام Design Patterns بشكل فعال، يجب على المطورين التركيز على الوضوح والمسؤولية.

تتضمن أفضل الممارسات المفيدة ما يلي:

  • ابدأ بالمشكلة، وليس بالنمط.

  • استخدم الأنماط فقط عندما تؤدي إلى تحسين الوضوح أو المرونة.

  • اجعل كل class يركز على مسؤولية واحدة.

  • استخدم interfaces حيث أنها توفر قيمة حقيقية.

  • استخدم Dependency Injection بدلاً من محددات مواقع الخدمة المخفية.

  • حافظ على controllers رقيقًا وانقل منطق العمل إلى الخدمات أو حالات الاستخدام.

  • استخدم repositories للحصول على منطق الوصول إلى البيانات ذي معنى.

  • استخدم DTOs عندما تحتاج بنيات البيانات إلى الوضوح.

  • استخدم events للآثار الجانبية المستقلة.

  • تجنب المبالغة في هندسة الميزات البسيطة.

تساعد هذه الممارسات Design Patterns في دعم المشروع بدلاً من جعله أكثر صعوبة.

قائمة مرجعية عملية قبل تطبيق النمط

قبل تطبيق نمط تصميم، اطرح هذه الأسئلة:

  • ما هي المشكلة المحددة التي أقوم بحلها؟

  • هل هذا النمط سيجعل الكود أسهل في الفهم؟

  • هل سيقلل من الازدواجية أو الاقتران؟

  • هل ستجعل التغييرات المستقبلية أكثر أمانًا؟

  • هل سيجعل الاختبار أسهل؟

  • هل الميزة معقدة بما يكفي لتبرير النمط؟

  • هل يستطيع مطور آخر فهم التدفق بسهولة؟

  • هل أتبع الاتفاقيات الإطارية؟

إذا كانت الإجابة بنعم على العديد من هذه الأسئلة، فقد يكون النمط اختيارًا جيدًا.

مسار التعلم الموصى به للمشاريع الحقيقية

للمبتدئين والمطورين المتوسطين، مسار التعلم العملي هو:

  1. تعلم أساسيات OOP: classes، والكائنات، وencapsulation، وinheritance، وpolymorphism، وabstraction.

  2. تعلم interfaces وDependency Injection.

  3. تعلم MVC وService Layer Pattern.

  4. تعلم Repository Pattern وDTO Pattern.

  5. تعلم المصنع والاستراتيجية للسلوك المرن.

  6. تعلم المحول للتكاملات الخارجية.

  7. تعلم المراقب والأوامر لـ events والوظائف ومسارات العمل.

  8. تعلم الديكور والinterface للتنظيم الهيكلي.

  9. الممارسة من خلال إعادة هيكلة الميزات الحقيقية، وليس فقط قراءة النظرية.

يساعد مسار التعلم هذا المطورين على الانتقال من OOP الأساسي إلى بنية المشروع الحقيقية خطوة بخطوة.

الاستنتاج

تكون Design Patterns مفيدة للغاية عندما تحل المشكلات الحقيقية في المشاريع الحقيقية. إنها تساعد المطورين على تنظيم منطق العمل وإدارة التبعيات ودمج الأنظمة الخارجية ونقل البيانات الهيكلية والتعامل مع إجراءات events وqueue والحفاظ على إمكانية صيانة التطبيقات أثناء نموها.

غالبًا ما تعمل الأنماط مثل Service Layer وRepository وDTO وFactory وStrategy وAdapter وDecorator وFacade وObserver وCommand وDependency Injection معًا في تطبيقات PHP وLaravel وSymfony الحديثة وتطبيقات المؤسسات.

ومع ذلك، ينبغي استخدام Design Patterns بعناية. يمكن أن يؤدي الإفراط في استخدام الأنماط إلى تعقيد غير ضروري، في حين أن تجاهلها يمكن أن يؤدي إلى كود فوضوية وهشة. أفضل نهج هو البدء البسيط، وتحديد مشاكل التصميم الحقيقية، وإعادة البناء نحو النمط الصحيح عندما يؤدي ذلك إلى تحسين الوضوح والمرونة وقابلية الصيانة.