٣ تقنيات برمجية قوية لإزالة الشروط الفوضوية

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

١. البرمجة الدفاعية: الإرجاع المبكر#

لنفترض أننا نقوم بتطوير نظام مصادقة المستخدم الذي يحتاج إلى التحقق من حالات المستخدم المختلفة قبل السماح بالوصول:

هذا الصود يحتوي على مشاكل هيكلية واضحة. إنه يستخدم هياكل if-else المتداخلة بشكل عميق، مما يجعل الصود صعب القراءة والصيانة. مع زيادة عدد التحقق من الشروط، يزداد مستوى التداخل، مما يشكل ما يسمى بصود "على شكل سهم". يتشتت منطق معالجة الأخطاء عبر مستويات تداخل مختلفة، وهو ما لا يسهل إدارة متوحدة. الأهم من ذلك، أن المنطق الأساسي للصود - الحالة التي يُسمح فيها بالوصول - مدفون بعمق داخل طبقات متعددة من الأحكام الشرطية، ويفتقر إلى الوضوح. هذا النمط البرمجي لا يقلل فقط من قابلية قراءة الصود ولكنه يزيد أيضًا من خطر الأخطاء ويجعل توسيع الصود صعبًا.

يمكننا تحسين هذا الصود باستخدام نهج "الإرجاع المبكر":

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

هذه الطريقة تجلب عدة تحسينات:

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

٢. طريقة الجدول المرجعي#

غالبًا ما نصادف سيناريوهات تحتاج فيها إلى إرجاع نتائج مختلفة بناءً على مدخلات مختلفة. إذا لم تتم الإدارة بشكل صحيح، فإن هذه المنطقات يمكن أن تتطور بسهولة إلى سلاسل طويلة من if-else أو عبارات switch ضخمة.على سبيل المثال، في منصة التجارة الإلكترونية، نحتاج إلى إرجاع أوصاف الحالة المقابلة بناءً على حالات الطلب المختلفة:

هذا سيناريو نموذجي لإرجاع نتائج مختلفة بناءً على حالات مختلفة. مع زيادة عدد الحالات، يصبح البيان switch أو أحكام if-else طويلة.علاوة على ذلك، في هذا السيناريو، إذا كان المستخدمون يحتاجون إلى ترجمة هذه المحتويات الحالة إلى لغات أخرى، فإن ذلك سيتطلب تعديل جسم الوظيفة أو إضافة وظائف جديدة، مما يجلب تكاليف صيانة كبيرة.

في هذه الحالة، يمكننا استخدام طريقة الجدول المرجعي لتحسين الصود:

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

٣. البرمجة الموجهة للواجهة#

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

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

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

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

عملية التنفيذ:

١. تحديد واجهة استراتيجية الترجمة:

٢. تنفيذ هذه الواجهة لكل موفر ترجمة:

٣. إعادة صياغة فئة TranslationService، تمرير الاستراتيجية كمعامل:

٤. استخدم الصود المحسن:

من خلال تحديد واجهة TranslationStrategy وإدخال البرمجة الموجهة للواجهة، حصلنا على الفوائد التالية:

• يمكن لـTranslationService استخدام استراتيجيات ترجمة مختلفة لكل مكالمة.
• يصبح إضافة موفري ترجمة جدد بسيطًا، فقط قم بإنشاء فئة استراتيجية جديدة واتباع الواجهة.
• يمكن أن يختار الكود العميل بشكل مرن الاستراتيجية لاستخدامها لكل ترجمة دون تعديل المنطق الأساسي لـTranslationService.
• يمكن اختبار كل استراتيجية ترجمة بشكل مستقل، مما يحسن من قابلية اختبار الصود.
• تجنب الحفاظ على حالة في TranslationService يجعل الخدمة أكثر عدم حالة وأكثر أمانًا للخيوط.

الخلاصة#

تحسين هياكل العبارات الشرطية هو وسيلة مهمة لتحسين جودة الصود. الطرق الثلاثة المقدمة في هذه المقالة - البرمجة الدفاعية، طريقة الجدول المرجعي، والبرمجة الموجهة للواجهة (مع تعدد الأشكال) - كل منها لها سياقات مناسبة:

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

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

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