في هذه الصفحة
المقدمة
الـ SOLID Principles من أهم المبادئ اللي وُجدت في عالم الـ Object Oriented Programming في اتجاه بناء Softwares قوية ، وتكون قابلة للصيانة والتغيير ، ولكن احيانا كتير عدم فهمنا الجيد ليها وتطبيقها بدون دراية كافية ممكن يبقى ليا أثر سلبي وتقلب ضدك.
فخلونا نشوف مع بعض ايه هي اسباب الـ Over Engineering اللي ممكن تحصل وازاي نقدر نتجنبها او نقلل منها.
أسباب الـ Overengineering في الـ SOLID Principles
أسباب Over Engineering في الـ SOLID:
- هو التزام صارم بالمبادئ دون مراعاة السياق: يمكن أن يؤدي تطبيق المبادئ بشكل آلي دون النظر إلى الاحتياجات الفعلية للمشروع إلى إنشاء تصميمات معقدة لا تضيف قيمة حقيقية.
- الخوف من التغييرات المستقبلية: قد يدفع المطورون إلى إنشاء تصميمات معقدة للغاية في محاولة لتجنب أي تعديلات مستقبلية، ولكن هذا يمكن أن يؤدي إلى تعقيد غير ضروري في الوقت الحالي.
- عدم الفهم الكامل للمبادئ: قد يؤدي سوء فهم أو تطبيق خاطئ للمبادئ إلى إنشاء تصميمات غير صحيحة أو غير فعالة.
آثار الـ Overengineering في الـ SOLID Principles
- تعقيد غير ضروري: يمكن أن يؤدي تصميم معقد للغاية إلى صعوبة فهمه وصيانته.انخفاض الأداء: يمكن أن تؤدي التصميمات المعقدة إلى زيادة عبء المعالجة، مما يؤدي إلى انخفاض الأداء.
- زيادة تكلفة التطوير: يمكن أن يؤدي التعقيد الزائد إلى زيادة الوقت والجهد اللازمين لتطوير وصيانة النظام.
مبادئ SOLID هي مبادئ قوية تهدف إلى تحسين تصميم البرمجيات وجعلها أكثر مرونة وسهولة في الصيانة. ولكن، كما ذكرت، إذا تم تطبيقها بشكل مفرط أو في سياقات غير مناسبة، قد تؤدي إلى overengineering، وهو جعل التصميم أكثر تعقيدًا من اللازم. لذلك، هناك حالات يجب فيها توخي الحذر وتجنب تطبيق مبادئ SOLID إذا لم تكن هناك حاجة فعلية.
متى تتجنب أو تقلل من تطبيق مبادئ الـ SOLID Principles
عندما يكون المشروع صغيرًا أو بسيطًا
في المشاريع الصغيرة أو البسيطة، يمكن أن يؤدي تطبيق مبادئ SOLID بشكل مفرط إلى تعقيد الكود بشكل غير ضروري.
الحل: ابدأ بتصميم بسيط وعملي. لا تطبق abstractions أو الفصل بين الطبقات إلا إذا ظهرت الحاجة بوضوح.
لا حاجة للتوسع والتغيير في المستقبل القريب
إذا كان المشروع أو الجزء المعني منه ثابتًا ولا يتوقع أن يتغير، يمكن أن يصبح من غير المنطقي إضافة واجهات أو فصل الوظائف بشكل مفرط.
الحل: لا تحاول التنبؤ بجميع التغييرات المستقبلية. تعامل مع الواقع الحالي ولا تبالغ في abstractions لمجرد افتراض التغيير.
عندما يزيد التعقيد عن الفائدة
قد يؤدي تطبيق المبدأ بطريقة صارمة إلى تصميم مبالغ فيه يتطلب المزيد من الجهد للفهم والصيانة، خاصة في فرق العمل الصغيرة أو إذا كان عدد المطورين محدودًا.
الحل: حافظ على توازن بين البساطة و abstractions. إذا كان abstract جزء معين يزيد التعقيد دون فائدة واضحة، فمن الأفضل تجنبه.
تقدروا دلوقتي تشتركوا في النشرة الأسبوعية لاقرأ-تِك بشكل مجاني تمامًا عشان يجيلكوا كل جديد بشكل أسبوعي فيما يخص مواضيع متنوعة وبشروحات بسيطة وسهلة وبجودة عالية 🚀
النشرة هيكون ليها شكل جديد ومختلف عن شكلها القديم وهنحاول انها تكون مميزة ومختلفة وخليط بين المحتوى الأساسي اللي بينزل ومفاجآت تانية كتير 🎉
Eqraatech - اقرأ-تِك
بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀
آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة
مستنينكوا تنورونا , وده رابط القناة 👇
عندما تحتاج إلى إصدار سريع
في حالات كثيرة، يكون الوقت من العوامل الحاسمة، مثل عند تطوير منتج بسرعة أو إجراء MVP (منتج ذو قيمة مبدئية). قد يؤدي التركيز على تطبيق SOLID إلى تأخير في التسليم.
الحل: في هذه الحالة، اعمل على الحلول السريعة التي تلبي المتطلبات الأساسية، مع الاحتفاظ بالمرونة لإعادة تصميم الكود لاحقًا إذا دعت الحاجة.
عندما تكون الميزات غير معقدة بطبيعتها
في بعض الأحيان، تكون الميزات بسيطة ولا تحتاج إلى التقسيم أو abstractions. تطبيق SOLID في هذه الحالات يمكن أن يؤدي إلى إنشاء طبقات غير ضرورية.
الحل: إذا كانت الميزة أو الوظيفة بسيطة بما يكفي، فقد يكون من الأفضل الاحتفاظ بتصميم مباشر وسهل دون استخدام مبدأ مثل الفصل بين الواجهات أو abstractions.
أمثلة عملية
- الـ (Open/Closed Principle): إذا كنت تعمل على مشروع صغير ولا تتوقع تغييرات كبيرة، قد لا يكون من المنطقي فصل الأكواد بشكل يجعل إضافة ميزات جديدة ممكنًا دون تعديل الكود الموجود.
- مبدأ التبعية العكسية (Dependency Inversion): إذا كنت تبني وظيفة بسيطة جدًا (مثلًا: إرسال بريد إلكتروني) ولا تتوقع تغيير الوسيلة أو الأداة المستخدمة، لا تحتاج إلى استخدام واجهة وطبقات مجردة.
- مبدأ واجهة الفصل (Interface Segregation Principle): إذا كان المشروع بسيطًا ولا يحتوي على العديد من الكيانات المعقدة، قد يكون تقسيم الواجهات إلى أجزاء أصغر غير ضروري.
كيفية تجنب الـ Overengineering
- التطبيق التدريجي: ابدأ بتصميم بسيط ومع مرور الوقت، إذا ظهرت الحاجة إلى التوسع أو تغيير التصميم، يمكنك إعادة تصميم الكود ليتوافق مع مبادئ SOLID.
- الاعتماد على الاحتياجات الحالية: مهم جدا جدا جدا جدا ، فلا تقم بتصميم الأنظمة بناءً على توقعات مستقبلية: قد لا تحدث أبدًا. قم بالتركيز على التحديات الحالية.
- التوازن بين البساطة والمرونة: حافظ على الكود بسيطًا ولكن مع مرونة كافية للتوسع في المستقبل.
- عدم المبالغة في abstractions: لا تفرض التجريدات فقط لأن المبدأ ينص على ذلك. إذا لم يكن هناك تعدد في الاستخدام أو حاجة لتغيير الوسائل، لا حاجة لتطبيق مبادئ مثل التجريد.
في الختام
مبادئ SOLID مفيدة جدًا ولكنها أدوات، ولا يجب استخدامها دائمًا في كل مكان. استخدمها بحكمة وتأكد من أنها تضيف قيمة فعلية إلى الكود، وليس مجرد تعقيد غير ضروري.
كنا اتكلمنا قبل كده في سلسلة كاملة عن الـ SOLID Principles تقدروا تشوفوها من هنا :
Mohamed Naif
Mohamed Naif
Mohamed Naif
Mohamed Naif
Mohamed Naif
