غالبًا ما أقابل مطورين لم يسمعوا بمبادئ SOLID (نحن . - الترجمة.) أو البرمجة الشيئية (OOP) ، أو سماعها ، لكن لا تستخدمها في الممارسة. توضح هذه المقالة فوائد مبادئ OOP التي تساعد المطور في عمله اليومي. بعضها معروف جيدًا ، والبعض الآخر ليس كثيرًا ، لذا ستكون المقالة مفيدة للمبرمجين المبتدئين وذوي الخبرة بالفعل.
نذكر: لجميع قراء "Habr" - خصم 10 روبل عند التسجيل في أي دورة Skillbox باستخدام رمز "Habr" الترويجي.
يوصي Skillbox بما يلي: دورة تعليمية عبر الإنترنت .
جاف (لا تكرر نفسك)
مبدأ بسيط إلى حد ما ، يتضح جوهره من الاسم: "لا تكرر نفسك". بالنسبة للمبرمج ، هذا يعني الحاجة إلى تجنب الكود المكرر ، وكذلك القدرة على استخدام التجريد في العمل.
إذا كان هناك قسمان متكرران في الكود ، فيجب دمجهما في طريقة واحدة. إذا تم استخدام قيمة مضمنة أكثر من مرة ، فإن الأمر يستحق تحويلها إلى ثابت عام.
يعد هذا ضروريًا لتبسيط الكود وتسهيل صيانته ، وهي المهمة الرئيسية لـ OOP. يجب ألا تسيء استخدام الاتحاد أيضًا ، لأن نفس الرمز لن يجتاز الفحص مع كل من OrderId و SSN.
تغيير التغليف
تتطور منتجات البرامج الخاصة بمعظم الشركات باستمرار. هذا يعني أن الكود بحاجة إلى التغيير ، ويجب الحفاظ عليه. يمكنك جعل حياتك أسهل مع التغليف. سيسمح لك هذا باختبار قاعدة الشفرة الحالية والحفاظ عليها بشكل أكثر فعالية. .
إذا كنت تكتب بلغة جافا إذن .
مبدأ الانفتاح / التقارب
يمكن تذكر هذا المبدأ بسهولة من خلال قراءة العبارة التالية: "يجب أن تكون كيانات البرامج (الفئات ، والوحدات النمطية ، والوظائف ، وما إلى ذلك) مفتوحة للتمديد ، ولكنها مغلقة للتعديل." في الممارسة العملية ، هذا يعني أنه يمكنهم السماح بتغيير سلوكهم دون تغيير شفرة المصدر.
هذا المبدأ مهم عندما تتطلب التغييرات على الكود المصدري مراجعات واختبار وحدة وإجراءات أخرى. لا تتغير التعليمات البرمجية التي تلتزم بمبدأ الفتح / المغلق عند تمديدها ، لذلك تقل المشكلات المتعلقة بها.
فيما يلي مثال على رمز ينتهك هذا المبدأ.
إذا كنت بحاجة إلى تغيير شيء ما فيه ، فسيستغرق الأمر الكثير من الوقت ، لأنه سيتعين عليك تغيير جميع أجزاء الكود التي لها اتصال بالجزء المطلوب.
بالمناسبة ، الانفتاح والانغلاق هو أحد مبادئ SOLID.
مبدأ المسؤولية الفردية (SRP)
مبدأ آخر من مجموعة SOLID. تقول أن "هناك سبب واحد فقط يقود إلى تغيير طبقي". الفصل لديه مهمة واحدة فقط. قد يكون لها عدة طرق ، ولكن يتم استخدام كل منها فقط لحل مشكلة شائعة. يجب أن تخدم جميع الطرق والخصائص فقط هذا.
تكمن قيمة هذا المبدأ في أنه يفك الارتباط بين جزء واحد من البرنامج والكود. تؤدي إضافة أكثر من وظيفة إلى فئة ما إلى إدخال علاقة بين الوظيفتين. وبالتالي ، إذا قمت بتغيير أحدهما ، فهناك فرصة كبيرة لإفساد الثانية المتعلقة بالأولى. وهذا يعني زيادة دورات الاختبار من أجل تحديد جميع المشكلات مسبقًا.
مبدأ انعكاس التبعية (DIP)
ما سبق هو مثال على رمز حيث يعتمد AppManager على EventLogWriter ، والذي بدوره يرتبط ارتباطًا وثيقًا بـ AppManager. إذا كنت بحاجة إلى طريقة مختلفة لإظهار الإشعار ، سواء أكان ذلك دفعة أو رسالة نصية قصيرة أو بريدًا إلكترونيًا ، فأنت بحاجة إلى تغيير فئة AppManager.
يمكن حل المشكلة مع DIP. لذلك ، بدلاً من AppManager ، نطلب EventLogWriter ، والذي سيتم حقنه باستخدام إطار العمل.
يتيح DIP إمكانية استبدال الوحدات الفردية بسهولة بأخرى عن طريق تغيير وحدة التبعية. هذا يجعل من الممكن تغيير وحدة واحدة دون التأثير على الوحدات الأخرى.
التكوين بدلا من الميراث
الطريقتان الرئيسيتان لإعادة استخدام الكود هما الوراثة والتكوين ، ولكل منهما مزاياها وعيوبها. يفضل الخيار الثاني عادة لأنه أكثر مرونة.
يمنحك التكوين القدرة على تغيير سلوك الفصل في وقت التشغيل من خلال تعيين خصائصه. عند تنفيذ الواجهات ، يتم استخدام تعدد الأشكال ، مما يعطي تنفيذًا أكثر مرونة.
حتى "جافا الفعالة" جوشوا بلوخ ينصح بتفضيل التكوين على الميراث.
مبدأ باربرا ليسكوف البديل (LSP)
مبدأ آخر من مجموعة أدوات SOLID. تنص على أن الأنواع الفرعية يجب أن تكون قابلة للاستبدال من أجل النوع الفائق. وهذا يعني أن الأساليب والوظائف التي تعمل مع الطبقة الفائقة يجب أن تكون قادرة على العمل دون مشاكل مع الفئات الفرعية.
يرتبط LSP بكل من مبدأ المسؤولية الفردية ومبدأ فصل المسؤولية. إذا كانت الفئة توفر وظائف أكثر من فئة فرعية ، فلن تدعم الفئة الأخيرة بعض الوظائف ، مما ينتهك هذا المبدأ.
هذا جزء من التعليمات البرمجية التي تتعارض مع LSP.
تحسب طريقة المنطقة (المستطيل r) مساحة المستطيل. سيتعطل البرنامج بعد تنفيذ Square ، لأن Square ليس مستطيلاً هنا. وفقًا لمبدأ LSP ، يجب أن تكون الوظائف التي تستخدم مراجع للفئات الأساسية قادرة على استخدام كائنات من الفئات المشتقة دون تعليمات إضافية.
هذا المبدأ ، وهو تعريف محدد لنوع فرعي ، اقترحته باربرا ليسكوف في خطاب رئيسي في مؤتمر عام 1987 بعنوان "تجريد البيانات والتسلسل الهرمي" - ومن هنا جاء اسمه.
مبدأ فصل الواجهة (ISP)
مبدأ صلب آخر. ووفقا له ، لا ينبغي تنفيذ الواجهة التي لا يتم استخدامها. يساعد اتباع هذا المبدأ النظام على البقاء مرنًا وقابلاً لإعادة التدوير عند إجراء تغييرات على منطق العمل.
في أغلب الأحيان ، يحدث هذا الموقف عندما تحتوي الواجهة على عدة وظائف في وقت واحد ، ويحتاج العميل فقط واحدة منها.
نظرًا لأن كتابة واجهة مهمة معقدة ، بعد اكتمال العمل ، فإن تغييرها دون كسر أي شيء سيكون مشكلة.
تتمثل ميزة مبدأ ISP في Java في أنه يجب تنفيذ جميع الطرق أولاً ، وعندها فقط يمكن استخدامها بواسطة الفئات. لذلك ، فإن المبدأ يجعل من الممكن تقليل عدد الأساليب.
البرمجة لواجهة وليس تنفيذًا
هنا كل شيء واضح من الاسم. يؤدي تطبيق هذا المبدأ إلى كود مرن يمكنه العمل مع أي تطبيق جديد للواجهة.
يجب عليك استخدام نوع واجهة للمتغيرات أو أنواع الإرجاع أو نوع وسيطة الأسلوب. مثال يستخدم SuperClass بدلاً من SubClass.
إنه:
أرقام القائمة = getNumbers () ؛
لكن لا:
أرقام ArrayList = getNumbers () ،
هنا تطبيق عملي لما قيل أعلاه.
مبدأ التفويض
مثال شائع هو أساليب equals () و hashCode () في Java. عند الحاجة إلى مقارنة كائنين ، يتم تفويض هذا الإجراء إلى الفئة المناسبة بدلاً من فئة العميل.
تتمثل ميزة هذا المبدأ في عدم وجود ازدواجية في التعليمات البرمجية ومن السهل نسبيًا تغيير السلوك. كما ينطبق على تفويض الحدث.
تتيح لك كل هذه المبادئ كتابة كود أكثر مرونة وجمالًا وموثوقية مع تماسك عالٍ وقارن منخفض. بالطبع ، النظرية جيدة ، ولكن لكي يبدأ المطور حقًا في استخدام المعرفة المكتسبة ، فإن الممارسة مطلوبة. يمكن أن تكون الخطوة التالية بعد إتقان مبادئ OOP هي دراسة أنماط التصميم لحل مشاكل تطوير البرامج الشائعة.
يوصي Skillbox بما يلي:
- دورة عملية .
- دورة تطبيقية عبر الإنترنت .
- دورة عملية لمدة عامين .
المصدر: www.habr.com