في المنشورات السابقة، اكتشفنا طريقتين مختلفتين للتعامل مع معالجة الدفع في Laravel:

• ارتباطات الخدمة المشفرة
• ملزمة سياقية.

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

في هذا الجزء الثالث والأخير، سنلقي نظرة على نهج أكثر مرونة: استخدام نمط المصنع. يتيح لنا نمط التصميم هذا اختيار التنفيذ المناسب لـ PaymentProcessorInterface بناءً على السياق (على سبيل المثال، الاختيار بين Stripe أو PayPal حسب الطلب).

تنفيذ نمط المصنع

يوفر نمط المصنع حلاً قابلاً للتطوير لحل عمليات التنفيذ المختلفة ديناميكيًا في وقت التشغيل. وإليك كيفية إعداده خطوة بخطوة.

الخطوة 1: إنشاء واجهة المصنع

أولاً، دعونا نحدد واجهة PaymentProcessorFactoryInterface التي توضح كيفية التعامل مع معالجات الدفع المختلفة.

تضمن هذه الواجهة أن أي مصنع نقوم بإنشائه سيكون لديه طريقة getProcessor، المسؤولة عن إعادة معالج الدفع المناسب بناءً على الوسيطة المقدمة (على سبيل المثال، "stripe" أو "paypal").


  
  
  الخطوة 2: إنشاء تنفيذ المصنع


بعد ذلك، سنقوم بتنفيذ المصنع الذي يحل معالج الدفع المناسب بناءً على مدخلات الموفر.







 يقوم هذا المصنع بتحديد معالج الدفع الصحيح ديناميكيًا بناءً على المدخلات المقدمة في وقت التشغيل. في هذا المثال، نعيد مباشرة مثيلات جديدة لـ StripePaymentProcessor وPayPalPaymentProcessor. إذا لزم الأمر، يمكن أيضًا حل هذه الفئات من حاوية خدمة Laravel لإدارة أفضل.


  
  
  الخطوة 3: تنفيذ معالجات Stripe وPayPal


تأكد من أن لديك كلاً من فئتي StripePaymentProcessor وPayPalPaymentProcessor اللتين تنفذان PaymentProcessorInterface.

مثال: معالج الدفع الشريطي







مثال: معالج الدفع عبر PayPal

وبالمثل، قم بتطبيق فئة PayPalPaymentProcessor، باتباع نفس النمط مثل StripePaymentProcessor.


  
  
  الخطوة 4: ربط المصنع في حاوية الخدمة


 للتأكد من أن المصنع متاح في جميع أنحاء تطبيق Laravel الخاص بك، تحتاج إلى ربط PaymentProcessorFactory بحاوية خدمة Laravel. يمكنك القيام بذلك في AppServiceProvider.

في App\Providers\AppServiceProvider.php، أضف ما يلي داخل طريقة التسجيل:



public function register()
{
    $this->app->singleton(\App\Contracts\PaymentProcessorFactoryInterface::class, \App\Services\PaymentProcessorFactory::class);
}




يطلب هذا الربط من Laravel استخدام PaymentProcessorFactory كلما تم طلب PaymentProcessorFactoryInterface، مما يضمن وجود مثيل واحد فقط من المصنع في جميع أنحاء التطبيق.


  
  
  الخطوة 5: استخدام المصنع في وحدة التحكم


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

مثال: وحدة التحكم في الدفع



paymentProcessorFactory = $paymentProcessorFactory;
    }

    public function makePayment(Request $request)
    {
        $provider = $request->input('provider'); // E.g., 'stripe' or 'paypal'
        $amount = $request->input('amount');
        $currency = $request->input('currency');
        $paymentDetails = $request->input('details');

        // Get the appropriate payment processor based on the provider
        $paymentProcessor = $this->paymentProcessorFactory->getProcessor($provider);

        // Use the selected payment processor to create a payment
        $response = $paymentProcessor->createPayment($amount, $currency, $paymentDetails);

        return response()->json($response);
    }
}




 في وحدة التحكم هذه، نقوم بإدخال واجهة PaymentProcessorFactoryInterface عبر حقن التبعية. عندما يُطلب الدفع، نحدد مزود الدفع (على سبيل المثال، Stripe أو PayPal) من الطلب، ونمرره إلى المصنع، ونحل معالج الدفع المناسب ديناميكيًا.


  
  
  الخطوة 6: التعامل مع موفري الدفع المختلفين


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


  
  
  خاتمة


 يوفر استخدام نمط المصنع في Laravel 11 أسلوبًا مرنًا للغاية لاختيار معالجات الدفع المختلفة في وقت التشغيل. فيما يلي ملخص للخطوات التي تناولناها:

• واجهة المصنع والتنفيذ: تم إنشاء مصنع يحل ديناميكيًا معالج الدفع الصحيح استنادًا إلى إدخال السلسلة.
• تطبيقات المعالج: التأكد من أن كلا من فئتي StripePaymentProcessor وPayPalPaymentProcessor تنفذان PaymentProcessorInterface.
• ربط حاوية الخدمة: ربط المصنع في حاوية الخدمة للسماح بالحقن السهل خلال التطبيق. التحديد الديناميكي في وحدات التحكم: استخدم المصنع داخل وحدة التحكم لتحديد واستخدام معالج الدفع المناسب ديناميكيًا بناءً على بيانات وقت التشغيل.

مبادئ تصميم البرمجيات وأنماط التصميم

لقد بدأنا هذا البرنامج التعليمي المكون من 3 أجزاء باستخدام معالج دفع واحد، مع تحديد مشفر، ثم كنا نستخدم تكوين in code("compile time") باستخدام Laravel Service Container Binding، ثم في هذا الجزء واصلنا إعادة البناء مع التصميم المبادئ وأنماط التصميم في الاعتبار، مما سمح لنا بإعادة صياغة الكود، وتحقيق ما يلي:

• المرونة الديناميكية: يسمح نمط المصنع باختيار معالجات دفع مختلفة في وقت التشغيل، مما يجعل تطبيقك أكثر مرونة وقابلية للتطوير.
• اقتران فضفاض: عن طريق إدخال المصنع، يتم ربط وحدات التحكم الخاصة بك بشكل غير محكم بمعالجات الدفع، مما يسهل إضافة أو استبدال بوابات الدفع في المستقبل.
• قابلية الصيانة: يوفر هذا النهج قاعدة تعليمات برمجية أكثر نظافة وأكثر قابلية للصيانة، خاصة عند التعامل مع خيارات الدفع المتعددة.

مع هذا الإعداد، لدينا الآن نظام قوي ومرن للتعامل مع المدفوعات في Laravel. إذا كنا بحاجة إلى دعم معالجات إضافية، فيمكننا بسهولة توسيع المصنع لدعم وتعديل منطق اختيار مقدمي الخدمة، والتعامل مع سيناريوهات منطق الأعمال المختلفة.