قامت الزائرة الجميلة "توحة المنتوحة" بزيارة احدى مواقع التسوق الالكترونية، وبعد قضاء مئات الساعات في التسوق واضافة عشرات البضائع في حقيبة تسوقها Cart، بدأت عملية البيع بالانتقال الى صفحة تنفيذ الطلب Order وتسجيل بيانات بطاقة الائتمان Credit Card، وعند الخطوة الاخير ضغطت على الزر "بدء عملية البيع" ولم تظهر نتيجة، ثم ضغطت عليه مرة اخرى ولم تظهر نتيجة (يبدو ان المشكلة في مزود خدمة الانترنت لديها)، واستمرت باعادة المحاولة اكثر من مرة حتى ظهرت لها رسالة "تم تنفيذ الطلب بنجاح! وسيتم شحن المنتجات اليك في الفترة المحددة". عندما جاء موعد التسليم، دق جرس المنزل ليصل مندوب شركة النقل حاملا بضائعها التي إشترتها، وكانت الصدمة الكبرى ان البضائع تكررت 8 مرات! والمصيبة الكبرى، انها وجدت 8 فواتير تحمل نفس البضائع، وعندما تحققت اكثر في سجل حسابها البنكي لبطاقة الائتمان Credit Card، صدمت بأن الطلب تم تنفيذه 8 مرات (والسبب انها ضغطت على الزر "بدء عملية البيع" ثمان مرات). ولو تخيلنا جدول الطلبات Orders في قاعدة بيانات الموقع، لكان شيئا مثل: في الحقيقة، المشكلة ليست في مزود خدمة الانترنت، ولا في شركة النقل، ولا في بطاقة الائتمان، ولا في بطلة القصة "توحة المنتوحة"، ولكن المشكلة في المبرمج المغفل الذي صمم صفحات عملية الشراء، فلم يطبق نموذج تصميمي Design Pattern شهير جدا اسمه "المنشيء (بضم الميم وكسر الشين) Maker والمؤكد (بضم الميم وكسر الكاف) Approver". تهدف فكرة هذا التصميم البرمجي بحماية العمليات المالية من الأخطاء الناتجة عن مشاكل الاتصالات في الشبكة، وتتبعه الانظمة البنكية Banking Systems بشغف كبير، مما يضمن حماية حقوق عملائها وجميع مستخدمي انظمتها بشكل عام. فعندما تقوم بتسديد فاتورة وتم قطع الاتصال او حدثت مشكلة في الخادم Server لحظة تنفيذ الطلب، يضمن لك هذا الاسلوب البرمجي بعدم تنفيذ العملية اكثر من مرة. ليس هذا فقط، بل حتى ان قمت بالضغط على زر "تنفيذ العملية" اكثر من مرة، يحميك هذا الاسلوب البرمجي من عدم تنفيذها اكثر من مرة. رائع ولكن كيف يتم ذلك؟ التصميم البرمجي "المنشيء Maker والمؤكد Approver" سخيف جدا جدا جدا، بل يتعدى مرحلة السخافة بكثير، ولا يحتاج الى شرح مفصل، حيث كل ما يطلبه هو تكوين عمليتين Two Transactions لتحقيق عملية مالية واحدة Single Financial Transaction، العملية الاولى تقوم بانشاء Makes الطلب او العملية المالية، والعملية الثانية تقوم بتأكيد Approves الطلب او العملية المالية. طريقة بنائه ليست محكورة على اسلوب موحد، حيث يمكنك ابتكار أي طريقة تودها، وابسط واسهل واسرع طريقة تكون باضافة حقول اضافية (مثل حقل تم التأكيد؟) تظهر ان العملية تم تنفيذها، ولو طبق الموقع هذا الاسلوب لكان جدول الطلبات شيئا مثل: تلاحظ في الجدول السابق ان عملية التأكيد Approving تمت على آخر سجل انشأ الطلب، وقد صممنا برنامجنا بحيث يتحقق من ان عملية التأكيد لا تتكرر بالخطأ (حتى ان تم الضغط على زر تنفيذ اكثر من مرة)، ويمكنك اضافة المزيد من الحقول كوقت التأكيد Approve Time. لا يقتصر اسلوب "المنشئ Maker والمؤكد Approver" على العمليات المالية فقط، بل يمكنك اعتماده على أي عملية حساسة Sensitive في نظامك، ويمكنك ايضا تطبيقه ان رغبت ان يشرف على العملية اكثر من شخص مسئول في النظام لتكون بمثابة توقيع اعتماد Approve لتنفيذ العملية. اعزائي المبرمجين، لا تنسوا تطبيق هذا الاسلوب البرمجي في مشاريعكم القادمة واحفظوا حقوق الناس، فهدفنا خدمة المستخدمين وليست تصيد اخطائهم :) -- تركي