تقديم ثلاث تقنيات برمجية قوية لتحسين وتبسيط الهياكل الشرطية المعقدة، مما يحسن جودة الصود وقابليتها للصيانة.
في تطوير البرمجيات، غالبًا ما نصادف منطق صود يحتاج إلى التعامل مع سيناريوهات متعددة. إذا لم تتم الإدارة بشكل صحيح، فإن هذه المنطقات يمكن أن تتطور بسهولة إلى سلاسل طويلة من if-else أو عبارات switch ضخمة. ستقدم هذه المقالة عدة تقنيات فعالة لتحسين هذه الهياكل، مما يحسن من جودة الصود وقابليتها للصيانة.
لنفترض أننا نقوم بتطوير نظام مصادقة المستخدم الذي يحتاج إلى التحقق من حالات المستخدم المختلفة قبل السماح بالوصول:
هذا الصود يحتوي على مشاكل هيكلية واضحة. إنه يستخدم هياكل if-else المتداخلة بشكل عميق، مما يجعل الصود صعب القراءة والصيانة. مع زيادة عدد التحقق من الشروط، يزداد مستوى التداخل، مما يشكل ما يسمى بصود "على شكل سهم". يتشتت منطق معالجة الأخطاء عبر مستويات تداخل مختلفة، وهو ما لا يسهل إدارة متوحدة. الأهم من ذلك، أن المنطق الأساسي للصود - الحالة التي يُسمح فيها بالوصول - مدفون بعمق داخل طبقات متعددة من الأحكام الشرطية، ويفتقر إلى الوضوح. هذا النمط البرمجي لا يقلل فقط من قابلية قراءة الصود ولكنه يزيد أيضًا من خطر الأخطاء ويجعل توسيع الصود صعبًا.
يمكننا تحسين هذا الصود باستخدام نهج "الإرجاع المبكر":
من خلال تبني استراتيجية "الإرجاع المبكر"، نجحنا في تحسين هيكل الصود الأصلي.
هذه الطريقة تجلب عدة تحسينات:
غالبًا ما نصادف سيناريوهات تحتاج فيها إلى إرجاع نتائج مختلفة بناءً على مدخلات مختلفة. إذا لم تتم الإدارة بشكل صحيح، فإن هذه المنطقات يمكن أن تتطور بسهولة إلى سلاسل طويلة من if-else أو عبارات switch ضخمة.على سبيل المثال، في منصة التجارة الإلكترونية، نحتاج إلى إرجاع أوصاف الحالة المقابلة بناءً على حالات الطلب المختلفة:
هذا سيناريو نموذجي لإرجاع نتائج مختلفة بناءً على حالات مختلفة. مع زيادة عدد الحالات، يصبح البيان switch أو أحكام if-else طويلة.علاوة على ذلك، في هذا السيناريو، إذا كان المستخدمون يحتاجون إلى ترجمة هذه المحتويات الحالة إلى لغات أخرى، فإن ذلك سيتطلب تعديل جسم الوظيفة أو إضافة وظائف جديدة، مما يجلب تكاليف صيانة كبيرة.
في هذه الحالة، يمكننا استخدام طريقة الجدول المرجعي لتحسين الصود:
أولاً، باستخدام كائن Map لتخزين العلاقة بين الحالات والأوصاف، يصبح الصود أكثر اختصارًا. لقد قمنا أيضًا بتسهيل نقل أوصاف الحالة إلى ملفات التكوين، مما يوفر سهولة في التدويل والتحديثات الديناميكية. عند إضافة حالات جديدة، لا نحتاج إلى تعديل الصود الأساسي، نحتاج فقط إلى إضافة أزواج المفتاح والقيمة المقابلة في التكوين.
عند تطوير أنظمة برمجية كبيرة، غالبًا ما نحتاج إلى دعم موفري خدمات متعددين أو وحدات وظيفية. يمكننا التفكير في استخدام البرمجة الموجهة للواجهة في مرحلة تصميم البرمجيات لتسهيل التوسعات اللاحقة، وبالتالي التخلص من تعقيد الأحكام الشرطية المتعددة الناتجة عن التشفير الثابت في الأنظمة المعقدة.
افترض أننا نقوم بتطوير نظام ترجمة متعدد اللغات يحتاج إلى دعم موفري خدمات ترجمة مختلفين. إذا لم نفكر في البرمجة الموجهة للواجهة من مرحلة التصميم، فإن التوسعات اللاحقة ستصبح صعبة جدًا:
يستخدم هذا التنفيذ هيكلًا بسيطًا وخامًا من if-else لاختيار موفري الترجمة، مما يجعل الصود صعب الصيانة والتوسيع. عند إضافة موفري ترجمة جدد في المستقبل، يتعين تعديل الصود الحالي، ومع زيادة عدد موفري الترجمة الذي يحتاجون للدعم، يصبح الصود مترهلًا وصعب الصيانة. في الوقت نفسه، تصبح هذه الطريقة المعقدة صعبة الاختبار الوحدوي لأنها ليست سهلة لمحاكاة موفري الترجمة المختلفين.
لحل هذه المشاكل، يمكننا استخدام البرمجة الموجهة للواجهة لتحسين الصود. البرمجة الموجهة للواجهة هي وسيلة مهمة لتنفيذ تعدد الأشكال، مما يسمح للأشياء المختلفة بالاستجابة بشكل مختلف لنفس الرسالة.
عملية التنفيذ:
١. تحديد واجهة استراتيجية الترجمة:
٢. تنفيذ هذه الواجهة لكل موفر ترجمة:
٣. إعادة صياغة فئة TranslationService، تمرير الاستراتيجية كمعامل:
٤. استخدم الصود المحسن:
من خلال تحديد واجهة TranslationStrategy وإدخال البرمجة الموجهة للواجهة، حصلنا على الفوائد التالية:
TranslationService استخدام استراتيجيات ترجمة مختلفة لكل مكالمة.TranslationService.TranslationService يجعل الخدمة أكثر عدم حالة وأكثر أمانًا للخيوط.تحسين هياكل العبارات الشرطية هو وسيلة مهمة لتحسين جودة الصود. الطرق الثلاثة المقدمة في هذه المقالة - البرمجة الدفاعية، طريقة الجدول المرجعي، والبرمجة الموجهة للواجهة (مع تعدد الأشكال) - كل منها لها سياقات مناسبة:
١. البرمجة الدفاعية مناسبة للتعامل مع تحقق من الشروط المستقلة ويمكن أن تقلل بشكل فعال من تداخل الصود. ٢. طريقة الجدول المرجعي مناسبة للتعامل مع الاحتياجات التي تتفاعل بشكل مختلف مع الحالات المختلفة، مما يجعل الصود أكثر اختصارًا وأسهل في الصيانة. ٣. البرمجة الموجهة للواجهة مع تعدد الأشكال مناسبة لبناء أنظمة معقدة ولكن مرنة، مما يحسن من مرونة الصود وسهولة توسعها.
في التطوير الفعلي، غالبًا ما نحتاج إلى اختيار الأساليب المناسبة بناءً على الحالات الخاصة، وفي بعض الأحيان نحتاج حتى إلى تطبيق تقنيات متعددة بشكل شامل. المهم هو موازنة البساطة وقابلية القراءة وقابيلة الصيانة للصود، واختيار الحل الذي يناسب المشكلة الحالية بشكل أفضل.
تذكر، أن الإفراط في تحسين الصود قد يؤدي إلى صود مفرط التعقيد. الحفاظ على بساطة الصود وقابليته للقراءة هو دائمًا المبدأ الرئيسي. عند تطبيق هذه التقنيات، يجب اتخاذ خيارات حكيمة بناءً على احتياجات المشروع المحددة ومستوى فريق العمل التقني.